CANBUS Bridge - A device used to determine the source of message IDs

Ideas and discussion of what to do with the CAN Bus ( i.e. XMDirect, iPod, Carputer, etc... )
Post Reply
User avatar
BiggRanger
How the heck did I end up here?
Posts: 9
Joined: 2020 Feb 03 10:45
Contact:

CANBUS Bridge - A device used to determine the source of message IDs

Post by BiggRanger »

Looking at a bunch of messages on the CANBUS is interesting, but in order to aid in deciphering what the message content is it helps to know what device it broadcasting what message ID.

I created a project I call the CANBUS Bridge using an Arduino Uno, and 2 CANBUS boards. This device gets placed between a module and the rest of the vehicle bus, and it logs the message IDs coming into each CAN board and rebroadcasts them to the other CAN board. Granted this is messy since you need access to the device and have to cut the CAN wires in order to insert this device into it, but sometimes sacrifices need to be made.

My sacrifice - a 2008 Durango: dashboard removed, all interior wiring accessible, almost everything still works and it still drives!
1230191158e.jpg
I've posted the project on my GitHub at: https://github.com/BiggRanger/CANBUS-Bridge
The important information is in the PDF (how to build and use it), and the Arduino source is there too.
Like my last project the CAN library needs to be modified to support the 83.333Kbps speed of the CAN-IHS in older Chrysler vehicles (notes are in the source code).
CanBusBridge.jpg
Now for the interesting stuff from the CAN Interior:
Device - Message IDs
Cluster = 0x013, 0x014, 0x02E, 0x0D0, 0x11D, 0x150, 0x159, 0x1C8, 0x210, 0x340, 0x35E, 0x3A0, 0x414
SKREEM = 0x012, 0x1B6, 0x1E0, 0x1E2, 0x1F6, 0x3EC, 0x400
TIPM = 0x000, 0x402 (these are known, there are more below)
Window Module Driver = 0x0BA, 0x408
Window Module Passenger = 0x1B8, 0x40A
HVAC = 0x0EC, 0x1F8, 0x411
Radio = 0x0F0, 0x18C, 0x190, 0x326, 0x3A5, 0x3AE, 0x3D0, 0x416
Airbag = 0x008, 0x41C
ECM via TIPM = 0x01B

These are the rest of the message IDs I have not documented the source for, they come from the TIPM but originate either from the TIPM, or some other device on the CAN-C network (since the TIPM acts as a CAN gateway).

CAN-IHS messages from the TIPM and CAN-C network:
0x002, 0x003, 0x006, 0x010, 0x011, 0x015 (maybe from ECU), 0x02C, 0x110, 0x18E, 0x19F, 0x1A5, 0x1A7, 0x1AD, 0x1AE, 0x1AF, 0x1B0, 0x1B2, 0x1B5, 0x1C0, 0x1D0, 0x1D2, 0x265, 0x370, 0x3F8

Notes about the project:
1) The supported CAN speeds are 80, 83.333, 125, 500Kbps.
2) Only standard CAN messages are supported, not extended messages.
Last edited by BiggRanger on 2020 Apr 15 13:26, edited 5 times in total.

uski
How the heck did I end up here?
Posts: 2
Joined: 2020 Feb 08 03:01

Re: CANBUS Bridge - Used to determine the source of message IDs

Post by uski »

That's very cool !
Do not hesitate to publicly document your findings, I just got started in this domain and for some reason it seems people jealously keep the CAN IDs and other info to themselves. I have no idea why. I will also publish all I find !

User avatar
BiggRanger
How the heck did I end up here?
Posts: 9
Joined: 2020 Feb 03 10:45
Contact:

Re: CANBUS Bridge - Used to determine the source of message IDs

Post by BiggRanger »

I'll be putting all my findings here:
https://github.com/BiggRanger/CANBUS-Ve ... ngineering
My work has slowed down a lot since everything is covered in snow right now, but as soon as it warms up again I'll be back at it.

CAN_do_attitude
How the heck did I end up here?
Posts: 6
Joined: 2020 Feb 13 16:31

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by CAN_do_attitude »

Hi! Nice work! Wondering if you can share some intel on VIN.

I have a low speed RER nav unit. It came with old firmware. All I had to do to change the vehicle make on the display was send 0x01B, with the following format:
0x01B - 0x00, 0x00, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00
where 0x43 was the ASCII representation of the vehicle model from the VIN (B (0x42) = Dodge, C (0x43) = Chrysler, J (0x4a) = Jeep, Z (0x5A) = Mitsubishi)

So, I upgraded the firmware to the latest (2.404) and now this trick doesn't work! I've even tried a full VIN from a known car (2008 Chrysler Sebring 1C3LC65M18N125174):
0x01B - 0x00, 0x31, 0x43, 0x33, 0x4C, 0x43, 0x36, 0x35 (1C3LC65)
0x01B - 0x01, 0x4D, 0x31, 0x38, 0x4E, 0x31, 0x32, 0x35 (M18N125)
0x01B - 0x02, 0x31, 0x37, 0x34, 0x00, 0x00, 0x00, 0x00 (174) - I've even tried padding the empty bytes with "0xFF" instead of "0x00".
The display still says "Dodge", even after a power cycle.

Care to share a CAN dump with the VIN bytes cycling?

Thanks,
Jeff

User avatar
BiggRanger
How the heck did I end up here?
Posts: 9
Joined: 2020 Feb 03 10:45
Contact:

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by BiggRanger »

Hi CAN_do_attitude,
I remember reading a long time ago that the RER radios will store the VIN on an EEPROM internally and sometimes use it as a security feature to prevent it from working in another vehicle with a different VIN. Chrysler has done the same thing with a lot of other devices on the CAN bus too, like the TIPM. That can't be used on another vehicle once the VIN has been learned. The TIPM must be what Chrysler calls "made virgin again" by erasing the VIN in the EEPROM that the TIPM. Once the VIN is blanked, then it can be plugged into a new vehicle and learn a new VIN.

Now for the VIN information....
On the IHS bus, there are 2 startup conditions for the VIN broadcast on ID 0x1B until the EMC is powered up.
1) A fresh reconnect of the battery. If the battery is disconnected the TIPM gateway, between the CAN-C bus (from the ECM) and the CAN IHS bus, does not have the last received VIN block in memory so it broadcasts the following ID: 0x1B Data: 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, every 100mS
2) After running, a key on event. The last broadcast of the VIN from the ECM is stored in the TIPM memory, so in your case you should see ID: 0x1B Data: 0x03, 0x4D, 0x31, 0x38, 0x4E, 0x31, 0x32, 0x35, every 100mS until the EMC is powered up and the VIN is broadcast again.

Also, if the TIPM stops getting the VIN from ECM, byte 0 of the ID 0x1B becomes 0x03 again.

Once the ECM is running and broadcasting you will see what you posted:
0x01B - 0x00, 0x31, 0x43, 0x33, 0x4C, 0x43, 0x36, 0x35
0x01B - 0x01, 0x4D, 0x31, 0x38, 0x4E, 0x31, 0x32, 0x35
0x01B - 0x02, 0x31, 0x37, 0x34, 0x00, 0x00, 0x00, 0x00
and the 0x1B ID is broadcast every 100mS.

The only thing I think happened was the new firmware learns the VIN and stores it in its EEPROM and it will take something else to erase the VIN so it can be reprogrammed.

CAN_do_attitude
How the heck did I end up here?
Posts: 6
Joined: 2020 Feb 13 16:31

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by CAN_do_attitude »

Ugh. That makes sense, though there's a small part of me that hopes it's not true.....

What I'll do is reprogram one of my CAN devices to send the VIN in a proper sequence, with some buttons to "cycle the key". I've been manually triggering alternate VIN messages in CANalyzer, but of course I can't follow the perfect 100ms timing that way (maybe it's timing out). If it still doesn't work maybe I'll try to find a friend with the diagnostic tool, to see if there's a way to reprogram the VIN. Hopefully it's not subject to seed & key. Or, maybe I can find someone with a Dodge that has low speed CAN. That would be a quick way to figure out if it is even possible.

I'll try rolling back the firmware to 9.807 too. Maybe that'll allow it to be switched before the 2.404 firmware "locks it in".

BTW, before I upgraded it to 2.404, the RER would also have a splash screen for Mitsubishi and Ferrari!

Thanks!

Edit - Rolling back to 9.807 is a no go. It just says "non-system disk error" when inserted. DOH!
Edit 2 - Ran the upgrade to 2.404 and it switched to Jeep. I found a "factory reset" option in a secret menu, now it says Chrysler again. I'm so confused!

User avatar
BiggRanger
How the heck did I end up here?
Posts: 9
Joined: 2020 Feb 03 10:45
Contact:

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by BiggRanger »

I've been using an Arduino to broadcast the CAN messages, the 100mS messages I've found need to be 100mS +/- 20 mS for everything to work right. I think when messages take more than 120mS something times out and needs to be reset.

By the way, please post how you got to the secret menu. It may help other people looking for help on the RER radios.

CAN_do_attitude
How the heck did I end up here?
Posts: 6
Joined: 2020 Feb 13 16:31

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by CAN_do_attitude »

Sorry, I didn't get any notice about the reply. I'm no closer to finding the solution, BTW. I did find a 2011 RBZ and another RER and they have the same behavior!

Does anyone have the RER 2.107 software? I can only find the 2.404 version and it has the newer logos, which some people might not like (like Dodge Ram owners).

OK, the RER "secret" engineering menu can be reached by holding the "menu" button and pressing "seek up" and "seek down" simultaneously. You get a warning message "Engineering is for HBAS internal use only. By clicking the OK button I accept any unknown risk." Of course, click OK and you're in. "Restore to Factory Defaults" is on page 4 of 5.

Edit: don't forget, once you perform the reset, the radio will be OFF. You have to press the knob/power (PUSH ON) to turn it back on. This seems to be often misinterpreted as a reset failure.

CAN_do_attitude
How the heck did I end up here?
Posts: 6
Joined: 2020 Feb 13 16:31

Re: CANBUS Bridge - A device used to determine the source of message IDs

Post by CAN_do_attitude »

I finally managed to get an RER put into a vehicle. The display said Chrysler, but after it was put into a Dodge vehicle the display changed to Dodge.

So, there's a sequence of CAN messages that makes it change teams. I just need a bit more time to figure it out. I hope it's just a matter of careful timing and sequencing of VIN messages (0x01B low speed or 0x219 high speed), because that's the one thing I haven't been able to simulate yet.

Post Reply