[stoopalini]

Big thanks to @stoopalini for allowing me to pick his brain and ask what he has attempted. Here is what I have found. The telematic unit must be removed and disabled to stop the Uconnect from disabling the Drive and Race Mode apps. I will be posting links below of where I found my information and where the Telematics unit is located. Once it is removed it must also be disabled in the BCM to stop any Uconnect errors. Then as Ddart said all you need to do is set Vehicle is SRT to yes. All pages will populate on a power cycle and the TNG panel will not work. You can get it to work until the radio restarts by then setting Vehicle is SRT to NO. As soon as the vehicle power cycles or you attempt to start the vehicle, the Radio will reboot and the Drive and Race modes will be gone. TNG are TBD at this moment, I have some idea and will try and report back. Forums are an amazing place. Please keep them that way and share information when you find. ✌

Apps Being Deleted Related Thread
Durango Telematic Location Thread

Awesome work man, I (we) appreciate your collaboration! I'm ordering the antennae bypass cable today to try it out. Good find!

For those reading ... the vehicle has several antennae in it, and they all converge into the Telematics box. Then there's one cable which goes from the telematics box to the radio which carries an aggregation of the antennae signals together. So the bypass cable allows you to remove the telematics box, and then bridge the Sirus/XM antennae cable to the other cable which normally carries the aggregate signal. This way, the radio still receives Sirus/XM and GPS signals but not cellular signals.

So you keep satellite radio and GPS navigation, but remove the ability for the Durango to "phone home". This means you'll lose any connected services features ... which I don't happen to use anyway.

Getting the drive mode buttons to retain functionality after a reboot I suppose is next. Interested to hear what you discover ...

Reading through the Ram thread, there are a couple of guys who took their trucks in for service after bypassing the telematics box and had no issues. Actually, a couple of them said the dealer did some software updates and they left with some new tow pages they weren't supposed to have. Most likely because their BCM was set to show them (due to making changes with AlfaOBD), so when the new firmware was flashed they appeared ... but because the telematics box is disconnected, the new pages weren't removed.

 

[stoopalini]

Just as an update to this .... @F8HEMI and myself have made good progress on developing a plan to work through the two remaining issues.

The first one being the disappearing of the apps. F8HEMI installed his antennae cable to bypass the Telematics box last night and it worked perfectly. SirusXM, GPS, Wireless CarPlay, etc ... are all still functional while the Telematics box is now disconnected. He also has the standard SRT dashboard tab (instead of the weird style my screen has) showing on his vehicle. So this is great news! My cable should be delivered today.

The 2nd issue we're trying to crack is being able to retain the TnG drive mode hard buttons with the SRT dashboard functional. This issue is a bit more complex. What we've found is that when "Vehicle is an SRT" is set to yes, the panel buttons are non-functional ... but if you change that setting in AlfaOBD back to "No", but do not start the engine or reboot the radio after making the change, the hard buttons will function again. In this state, the drive mode screens on the uConnect do not work for touch input though.

I believe this is due to "Vehicle is an SRT" now being set to "No", so the uConnect won't allow touch input as the TnG panel is overriding it.

A guy on the RAM forum is helping me work through this and has suggested installing a device which can intercept the CANBUS messages being sent to the TnG drive mode panel, and spoofing the message to make the panel think "Vehicle is an SRT" is actually set to "No", even though it would be "Yes" for all other modules in the vehicle.

The user helping me work through this has done it on his RAM already to enable other vehicle functions his BCM doesn't support. He's provided me with the details on the hardware he used as well as the code he's using and I'm going to attempt to leverage it for us.

The basic idea is to intercept the canbus cable connecting the drive mode panel to the canbus network, and insert a dual canbus arduino into that signal. So the arduino receives the messages intended for the control panel, makes a change to the message related to "VehConfig 3" settings to spoof "Vehicle is SRT" being set to "No", and then forward along to the panel.

I have the hardware ordered and the RAM forum user gave me his code, which I'll look at later today.

What I don't know right now is where to find the StarBus block where all the canbus cables connect together. I found the one located on the left side of the passenger's foot well, but the RAM user told me that one is the C bus hub for the chassis control modules. He said I should be looking for one that is white with a bunch of green connectors plugged into it and it is a part of the instrument panel harness, so it would be somewhere in the dash, or close to it.

If anyone knows where this is, please let us know ... otherwise F8HEMI and myself will start digging around looking for it.

More to come, but if this will work as I think it will, we will be able to provide information for folks to do this themselves if they so choose.

At the end of the day, I believe it will result in having the SRT dashboard with perf, drive mode, and race options available as well as having the TnG panel buttons being functional.

What's unknown right now is if the Custom Drive mode will still be accessible in the uConnect when the TnG panel is operational. Right now, those two things cannot coexist because setting "Vehciel is an SRT" to "No" (which is required to make the panel work) also prevents you from accessing the Custom Drive Mode. But after the spoofing trick, I'm hoping this will be possible.

More to come as we work through it

 

[Duh-rango]

If you are looking for the can bus topography it can be found on chilton site under wire diagrams. Or you can just look at pinouts for an ECM to see which pair of wires you need. On the CT forum I was helping a guy can bus sniff how the odometer updates and tapped into a pair of lines in the cluster. The obdlink interface was not fast enough to grab the packets but apparently the tazer is capable of sniffing the bus but never got it to work (a member contacted Zatuo and they apparently told him how but it was never shared) so I used an arduino with can bus shield and hyperterminal to grab the packets.

Can bus sniffing and programming is something I never took time to grasp but the CT member got what he needed and was well versed in hacking the cluster on the challenger. This was the thread which he was able to get the cluster to do what he wanted. However, never followed up to see if he installed it in his 77 celica?

https://www.challengertalk.com/threads/odometer-updating.680318/post-8736497

Anyways, hope this helps you get what you need.

 

[Duh-rango]

Nevermind you are looking for the starbus.

 

[stoopalini]

If you are looking for the can bus topography it can be found on chilton site under wire diagrams. Or you can just look at pinouts for an ECM to see which pair of wires you need. On the CT forum I was helping a guy can bus sniff how the odometer updates and tapped into a pair of lines in the cluster. The obdlink interface was not fast enough to grab the packets but apparently the tazer is capable of sniffing the bus but never got it to work (a member contacted Zatuo and they apparently told him how but it was never shared) so I used an arduino with can bus shield and hyperterminal to grab the packets.

View attachment 131097
View attachment 131099


View attachment 131098
View attachment 131100

Can bus sniffing and programming is something I never took time to grasp but the CT member got what he needed and was well versed in hacking the cluster on the challenger. This was the thread which he was able to get the cluster to do what he wanted. However, never followed up to see if he installed it in his 77 celica?

https://www.challengertalk.com/threads/odometer-updating.680318/post-8736497

Anyways, hope this helps you get what you need.

Thanks. I ordered a dual CAN Arduino dev board and will use this and place it "in line" with the CAN signal going to the control panel. It's a bit pricey at $100, but will be nice to not have to solder things together like my previous ESP/Arduino projects. And ... this dev board can take a 12v power source input which is a huge bonus.

I can never seem to find those diagrams in the Chiltons online site. What I'm looking for is the location of the star bus hub to which the control panel is connect. The user on the RAM forum told me it's not the C Network, but is the IHS network.

The images you pasted above seem like they might show it, but they're too small for me to zoom in on. How are you accessing these on the Chilton's site?

 

[stoopalini]

If you want to tap into the Can C bus, one location to tap into that I found to be fairly easy is the cluster...at least on challengers. Below is a 2021 durango cluster pinout.
View attachment 131105

Right, but I need to intercept the CAN bus wires leading to the control panel in order to block the VehConfig 3 message and then spoof a new value.

 

[Duh-rango]

How are you accessing these on the Chilton's site?

 

[stoopalini]

View attachment 131114

Thanks ... I'm finding this info there ...

Where I can tell the HVAC control panel is connected to port 5 of the IHS star bus hub

But I can't seem to find an image showing the physical location of the IHS star bus hub in the chassis.


Where are you finding this:

When I look under wiring diagrams, I'm only seeing the functional view but not a physical view

 

[Duh-rango]

For bus topography on

Where are you finding this:

View attachment 131116

Oh the topography, at first I was losing my mind trying to find it again but I must have selected 2020 by accident when I initially visited chilton but on subsequent visits I was selecting 2021.

Not sure if there is a difference between 2020 and +2021 but same module PNs seemed to be shared between those years?

 

[Duh-rango]

I wonder if DIYAlldata has that info for +2021 models?

 

[stoopalini]

Got it! Thanks.

I'm sure the IHS Star Bus hub is in the same location. Looks like it's in the driver's side footwell ... or, maybe behind the steering wheel? Tough to tell.

 

[stoopalini]

For some technical fun ....

If you look at an AlfaOBD backup file (not a log, but the backup file) you'll see a string of numbers.

The 1st two characters in any string represent the action ... in this case, "62" means a read action

The next 4 represent the "Request Code" which identifies a category of settings. In this case, "0124" is representing the "VehConfig 3" category.

We know that "Vehicle is an SRT" is within the "VehConfig 3" category by looking at the AlfaOBD log file:

Here is the full listing of category codes:

So taking the appropriate line out of the backup file for VehConfig 3 (ie: 0124 in character positions 3-6) and analyzing it ... this is what you get:

These characters are HEX, and represent binary. Four binary values per Hex character. The user on the RAM forum told me the 1st character of Byte 3 (ie: the 13th character) is where the "Vehicle is an SRT" setting is considered. He also told me what other 3 settings are there.

It breaks down like this...

For the default factory values it's:

If you change "Vehicle is an SRT" to "Yes", then it's:

So with "Vehicle is an SRT" set to "Yes", the BCM will be sending out messages on "0124" request code with the 1st character of Byte 3 set to 6. If this reaches the control panel, then the TnG hard buttons won't work.

So the Arduino will go inline with the CAN bus wires connecting the control panel with the IHS Star bus hub, and it will look for messages with "0124" in the request code. When found, it will replace the 1st character of Byte 3 with whatever value I tell it to ... In this case I'll replace it with HEX 2 so the control panel doesn't know "Vehicle is an SRT" has been set to "Yes" but thinks it is still "No".

The Arduino code looks pretty simple, mainly due to there being a nice include library for canbus.

I know this is getting highly technical, but hopefully in the end there is an easy way for others to duplicate the final outcome.

 

[stoopalini]

For those following along, here is a diagram depicting the hardware integration F8HEMI and myself will be trying in order to retain the TnG panel drive mode buttons along with the SRT dashboard being functional.

You unplug the control panel's green connector from port C5 of the OEM IHS starbus hub (orange + white wires), then either cut the little key tab off the green connector it so it'll fit into the spare 5 port green hub being added, or ... swap the green connector out for a white 2-2138650-1 connector.

Basically, green connectors plug into white blocks and white connectors plug into green blocks. This is due to the way the connectors are keyed. But ... you can cut the keys off the connectors so it could be plugged into either a white or a green block if you want. Which may make sense if you wanted to quickly put it back to OEM without needing to swap connectors again.

Then load the code onto the Arduino and hook it up as shown.

So all messages being sent to the control panel are passing through the Arduino and the specific message I outlined above gets modified on the way.

Hardware has all been ordered, just awaiting shipment now.

 

[stoopalini]

Got it! Thanks.

I'm sure the IHS Star Bus hub is in the same location. Looks like it's in the driver's side footwell ... or, maybe behind the steering wheel? Tough to tell.

View attachment 131120

Thanks to @F8HEMI for locating the IHS Starbus. It's behind the driver's side knee bolster.

He also confirmed C5 (5th connector when counting from the bottom and including the 3 pin connector) is confirmed to be the cable leading to the center stack control panel. Confirmed through a multimeter continuity check.

 

[stoopalini]

It's been a while since we've provided an update ... so here it is for anyone following along ...

We 1st tried injecting the Arduino in between the integrated center stack (ICS) and the IHS canbus, setting "Vehicle is an SRT" in the BCM to "Yes", and using the Arduino to spoof "Vehicle is an SRT" to "No" just for the ICS.

So setting up the hardware like this:

And logically, it looks like this ... where the Arduino is inserted at point A

This didn't work, and the TnG hard buttons still didn't work along with the SRT drive mode screens.

So next we tried moving the Arduino to between the security gateway module and the IHS bus, setting "Vehicle is an SRT" in the BCM to "No", and then spoofing "Vehicle is an SRT" as "Yes" to the SGW and everything behind it for messages received over the IHS bus (so the UC5 is included in that).

Here is the hardware view:

And here is the logical view, with the Arduino inserted at point B:

With this configuration, we have progress! The SRT dashboard is showing up and the TnG panel buttons function to control the drive modes; even after several reboots and engine start cycles. Drive mode changes made by pressing a TnG panel button are also reflected in the uconnect screen, but the touch screen input is not working to change drive modes. This means we can't access the "Custom" drive mode and also cannot make any changes to the individual sub-options within each drive mode. So not perfect, but good progress none the less.

Here's a quick video demonstrating how it's working in this config:

What I think is happening is that something on the C-bus actually controls the 'currently active' drive mode, and continually broadcasts this out ... while the ICS and uConnect just serve as inputs for generating a message to request a drive mode change .... then the BCM would pass this request message from the IHS-bus to the C-bus, and whatever on the C-bus is controlling drive modes would respond to it.

I think when "Vehicle is an SRT" is set to "Yes" in the BCM, it may only be allowing drive mode request messages from the uConnect to pass from the IHS-bus to the C-bus ... conversely ... when "Vehicle is an SRT" is set to "No" in the BCM, it is only allowing drive mode request messages from the ICS to pass to the C-bus.

Thus when the setup is in the current config, and I try to change drive modes VIA the uconnect ... the screen takes the input and you see the icon light up. It's most likely then sending out a drive mode request message on the IHS-bus but the BCM is not forwarding that to the C-bus becasue the "Vehicle is an SRT" setting is only expecting ICS messages. So a split second after making the touch screen input, whatever is the "master" device on the C-bus controlling the drive mode, broadcasts out the currently active mode ... so the uConnect screen reverts back almost instantly.

So I think the way to do this is to set "Vehicle is an SRT" to "Yes" in the BCM, move the Arduino back to position A in the above diagrams, and then program the Arduino to listen for drive mode request messages coming from the ICS and translate them into messages which appear to be coming from the UC5. If this can be done, then I should be able to get both the touch screen input as well as the TnG panel hard buttons working simultaneously, as well as Custom and the sub-options working too.

So next step is to start digging into canbus logs and sifting through the messages, to identify the structure of the ICS and the uConnect drive mode request messaging.

More work to do, but making slow and steady progress. HUGE thanks to @F8HEMI as well! He's been a massive help in all of this and there is no way we would be as far along as we are without it. I'm pretty confident we'll get there .. eventually!

 

[Sykadelick]

It's been a while since we've provided an update ... so here it is for anyone following along ...

We 1st tried injecting the Arduino in between the integrated center stack (ICS) and the IHS canbus, setting "Vehicle is an SRT" in the BCM to "Yes", and using the Arduino to spoof "Vehicle is an SRT" to "No" just for the ICS.

So setting up the hardware like this:

View attachment 131479


And logically, it looks like this ... where the Arduino is inserted at point A

View attachment 131480


This didn't work, and the TnG hard buttons still didn't work along with the SRT drive mode screens.

So next we tried moving the Arduino to between the security gateway module and the IHS bus, setting "Vehicle is an SRT" in the BCM to "No", and then spoofing "Vehicle is an SRT" as "Yes" to the SGW and everything behind it for messages received over the IHS bus (so the UC5 is included in that).

Here is the hardware view:

View attachment 131484


And here is the logical view, with the Arduino inserted at point B:

View attachment 131482


With this configuration, we have progress! The SRT dashboard is showing up and the TnG panel buttons function to control the drive modes; even after several reboots and engine start cycles. Drive mode changes made by pressing a TnG panel button are also reflected in the uconnect screen, but the touch screen input is not working to change drive modes. This means we can't access the "Custom" drive mode and also cannot make any changes to the individual sub-options within each drive mode. So not perfect, but good progress none the less.

Here's a quick video demonstrating how it's working in this config:

What I think is happening is that something on the C-bus actually controls the 'currently active' drive mode, and continually broadcasts this out ... while the ICS and uConnect just serve as inputs for generating a message to request a drive mode change .... then the BCM would pass this request message from the IHS-bus to the C-bus, and whatever on the C-bus is controlling drive modes would respond to it.

I think when "Vehicle is an SRT" is set to "Yes" in the BCM, it may only be allowing drive mode request messages from the uConnect to pass from the IHS-bus to the C-bus ... conversely ... when "Vehicle is an SRT" is set to "No" in the BCM, it is only allowing drive mode request messages from the ICS to pass to the C-bus.

Thus when the setup is in the current config, and I try to change drive modes VIA the uconnect ... the screen takes the input and you see the icon light up. It's most likely then sending out a drive mode request message on the IHS-bus but the BCM is not forwarding that to the C-bus becasue the "Vehicle is an SRT" setting is only expecting ICS messages. So a split second after making the touch screen input, whatever is the "master" device on the C-bus controlling the drive mode, broadcasts out the currently active mode ... so the uConnect screen reverts back almost instantly.

So I think the way to do this is to set "Vehicle is an SRT" to "Yes" in the BCM, move the Arduino back to position A in the above diagrams, and then program the Arduino to listen for drive mode request messages coming from the ICS and translate them into messages which appear to be coming from the UC5. If this can be done, then I should be able to get both the touch screen input as well as the TnG panel hard buttons working simultaneously, as well as Custom and the sub-options working too.

So next step is to start digging into canbus logs and sifting through the messages, to identify the structure of the ICS and the uConnect drive mode request messaging.

More work to do, but making slow and steady progress. HUGE thanks to @F8HEMI as well! He's been a massive help in all of this and there is no way we would be as far along as we are without it. I'm pretty confident we'll get there .. eventually!

Fantastic work all of you! This thread has been a very interesting read.

Eagerly following along.

 

[stoopalini]

I've been waiting to post this info to ensure it is permanent, and now feel it is ...

We've figured out what is causing the Drive Mode and Race Options apps to disappear from the Dashboard, and it is the Telematics Box's (TBM) "Connected Services" doing it. So there are 3 ways to address this ... you only need to implement one of the 3 methods:

1. Bypass the TBM all together by disconnecting all of the connectors from it
   • Use a Male to Male antennae adapter cable to connect the SXM/GPS antennae cable to the uConnect to retain nav and satellite radio functionality
   • Will lose LTE Internet connectivity which means the SXM voice search and on-demand channels will not function
2. Call Dodge/uConnect and request to "opt out" of connected services for privacy reasons. This will prevent the vehicle from being able to send data to the central servers
   • See post# 159 by F8HEMI for details on this
3. Use AlfaOBD (or similar) to disable the "Connected Services" feature in the BCM, located within the ECU Config 18 section.

I initially implemented #1, and it worked ... but the wife wasn't happy about no longer having access to her favorite SXM channels, since they are the on-demand ones.

Attached you'll find a PDF outlining the procedure for accessing the TBM, and here is what it looks like with the antennae bypass cable in place:

F8HEMI implemented #2 several weeks back, and his apps have persisted.

I since reconnected the TBM and then implemented #3 about 2 weeks ago, and the apps are still present.

A little tip someone gave me about using Alfa, since I was not able to see ECU Config 18 when accessing the BCM initially, thus did not know there was a "Connected Services" option:

Here’s a trick for exposing settings you can’t see while connected to the body computer that alfaobd automatically connects to (you’ll notice it doesn’t matter which MY you select, it automatically connects to the variant it detects):

• Connect to the body computer like you normally would.
• Switch over to advanced mode, and drop down the box that lists all of the vehicle body computers, and choose something like DT 1500 MY 2023+, or DJ 2500 MY2023+.
• Do not hit connect again, but just go straight to car configuration change, and you’ll have the ECUConfig 18 settings to change.
• You can also read the system ID while it’s in this state, and ECUConfig 18 will populate on your read log.

 

[stoopalini]

We've reached a pretty major milestone in this project yesterday, as I finally had enough conclusions from analyzing the data we've collected through various logs, to attempt to write the code for the microprocessor.

I ended up switching from the Arduino Due to a Teensy 4.0 processor. I did this because the Teensy has 3 canbus controllers on board and I initially thought I was going to have to not only intercept the IHS canbus for the Integrated Center Stack (ICS), but also interface to the C-bus. Turns out the connection to the C-bus isn't needed, but I'll keep the Teensy since it's a much faster processor than the Arduino; and I may want to add other functionality in the future (like RGB LEDs under the hood scoops which change color based on drive mode selection, and change intensity based on RPM or Boost, etc ...). Essenitally, the speed of this Teensy would allow me to add whatever I want and never risk lag on the canbus communications because it's so fast (600mhz Cortex-M7 processor!).

Here is a link to an Excel with details on the key CAN IDs which I ended up using to implement this initial code.

Stoop's CAN ID Excel File

... here's how the Teensy is logically integrated into the canbus (at point D):

And here's the wiring for it:

So I have the Teensy acting as "Man-in-the-Middle" between the ICS TnG panel and the IHS Canbus hub, and I'm translating messages on the IHS bus into what I think the ICS needs for LED control. Then it's also listening for button presses on the ICS center stack, and translating them into the message which the radio would have sent if the same function was selected on the touch screen.

And ... it's working beautifully! The only thing which I haven't solved yet is the Sport mode button LED and the EVIC splash for Sport mode. I thought I had it figured out, as the data seems to point to CAN ID 305, Byte 2, Bit 2 as the flag for the Sport LED. But there must be something I am missing. More investigation needed on this piece .... but everything else is now functioning

Here's a video demonstrating current state of this project:

 

[stoopalini]

More progress on fine tuning this setup.

I was annoyed I had to tap on the screen 4-5 times in order to activate Custom, and since I'll never really need quick access to Snow, I put some code in to allow repurposing the Snow button as the SRT button instead.

I may add more code to allow the user to switch this repurpose on and off with some button combination .. maybe holding MUTE down for 2 seconds, then pressing the Snow button ... or something similar.

Anyway ... I'm really enjoying the result of this so far

 

[80363]

You can pop off the SRT button on your SRT center stack and put it on your TNG center stack