Chrysler 300M Enthusiasts Club
  • Retrofitting a modern 8.4" UConnect radio

  • Discuss Custom or Factory Audio Systems
Membership Banner

Discuss Custom or Factory Audio Systems

Moderator: Moderators

 #378880  by 00R/T
 May 1st, 2019, 9:17 am
For the past few months (since before I got my car, actually) I've been working on a rather ambitious project - getting one of the 8.4" radios found in most current production FCA vehicles working in an LH. The new radios are heavily reliant on the CAN bus (PowerNet architecture, specifically), which complicates thing quite a bit. They don't even have a switched power lead. Rather, there is only a constant 12V connection and they will only turn on when they receive a CAN message telling them the ignition is.

So, given the amount of effort required, why go with a factory radio when there are many aftermarket options that would actually be cheaper in the long run? First, I've never seen an aftermarket radio that didn't look, well, aftermarket. I really appreciate the cleanliness of the factory units with no tiny buttons or knobs. In addition, I think that the ATC head is the other major thing other than the radio that makes the interior look dated. I wanted to eliminate it, and have the screen (and possibly modern hard buttons below) take its place. Finally, I really like doing stuff that people insist is impossible. This is going to be a very long read, and probably more info than anyone needs, but I figure this will serve as a good place to document my progress. If people are paying attention, it'll help keep me accountable too and make me finish it!

I'm going to be focusing primarily on the electronic/communications side of things as that is the big unknown. Given the number of people here with double DIN radios, I'm pretty confident that I can find someone who can modify the bezel for it once I'm done.

My goal:
  • Full functionality of audio features (Sirius, iPod, AM/FM)
  • Apple CarPlay
  • Steering Wheel Controls
  • Handsfree calling & voice control
  • Backup camera
  • Full control/display of HVAC system & heated seats
The first step in the process was getting the radio to turn on and function outside of a vehicle. While my eventual goal is to use one of the latest models that has CarPlay and the higher resolution display, I decided to do my development with a 2015 model I had. I was the first person with a RAM to upgrade to the CarPlay radio (the year before they offered it from the factory), so I know what I'll need to do to switch down the road.

I began this work by taking a log of the bus traffic in my truck, and playing it back to the radio. I then painstakingly went through message by message to figure out the minimum required messages to allow it to operate. Once I got to that point, I began to try to determine what these messages meant. Many of them are static, and can just be hard-coded by the sender. Things like what features the vehicle has (like heated or cooled seats) or the VIN, for example. I learned through this process that there are a lot of little tricky bits. Even if you report the key on, the radio won't turn on unless you send the VIN. It must be a valid VIN, too, as it runs the calculation and verifies the check digit. You also need to send the same VIN every time you power on, or it will go into anti-theft mode and require you to enter the unlock code again. Another one that beat me up for a while is that the default country is not the US, and if you don't explicitly tell it that it's a US domestic market vehicle then it will hide the Sirius mode. Once I had all my static messages sorted out and setup for my car (correct VIN, destination country, vehicle brand for the splash screen, heated but not cooled seats, etc.), I pulled out my familiar Arduino with a CAN shield and set that up to do the message sending in a loop rather than me doing it manually from my computer.

With the static messages out of the way, I moved on to the dynamic ones. I identified that the minimum values I must send would be the ignition position, whether the parking lights are on (to switch the display to night mode), whether the car is in reverse or not (for backup camera), the steering wheel audio control button events, and the ATC status (fan speed, vent position, temp, auto/on/off, defrost, etc.). I eventually was able to figure all these out, and could simulate sending them from my PC.

The CAN analysis work was largely done at this point, so I moved on to the PCI bus side. I would need to be able to read all the dynamic values from the PCI bus in the car, so I could convert them and then pass them on via CAN. I started doing this using the popular ELM327 chip dumping serial data to my PC and eventually was able to identify the values that I needed. I then attempted to use the ELM327 with the Arduino, but I found that I could not process the incoming messages quickly enough. I switched to the improved version of that chip, the STN1110, because it had a message filter. Once I was able to filter only the messages I needed, I was able to handle them with the Arduino.

Testing the whole solution in the car was going to be difficult due to the components being on multiple boards, lots of jumper wires, different voltage levels, etc. However, I decided that I had enough individual pieces working that I decided the design was viable enough to produce a custom PCB. I designed the circuit that would include the power supply, CAN interface and STN1110 and laid it out as an Arduino shield so I could just pop it on top of my Arduino in place of the CAN-only shield I was currently using. I figured if it worked, I'd end up adding the Arduino circuitry to the design and then making a single board.

I worked on cleaning up and integrating all the software while I waited for the bare PCBs to be made. When they finally arrived, I built one up. It was extremely difficult due to the package size of the STN1110 chip I had to use in order to fit in on the shield board. I fought with it for a while, and eventually ended up hanging my old larger STN1110 off the side using jumper wires. I started bench testing it, and found that the performance was poor when heavily loading the PCI bus and attempting to send all the required CAN messages. After realizing there were inherent limitations due to the design of the STN1110 interface and the Arduino, I made the difficult decision to abandon my plan and start from scratch.

Since I was starting from scratch, I wanted full control of everything and decided not to use any off-the-shelf interface chips. I also did not want the overhead of the Arduino architecture. Rather, I designed a circuit that included an MCU with an integrated CAN peripheral and a capture compare input for the PCI signals. It also used a highly efficient switching regulator to minimize heat when knocking the voltage down from 12V to 5V. The focus was on minimizing component count and board size, and I was able to get it into a 1"x2" PCB with a single latching connector. The idea was that instead of a fairly large unit I'd have to mount somewhere, this could just be tied to the harness I'd be building to go between the radio connector in the car and the new radio. While I was waiting for the board to be manufactured, I built up a replica of the circuit on a breadboard and began the software development work.

I had structured my previous software well, so I was able to largely re-use most of the higher-level functions that did the actual data conversion. However, since I was moving to bare metal, I had to get the CAN running, and also write an optimized version of a J1850 VPW interpreter that would be completely interrupt driven in order to meet the high demands of the outgoing CAN traffic. Things went fairly smoothly until this past Sunday. I was almost at the point where I thought I could test the boards once they arrived, but I ran into a problem I just couldn't solve. The boards showed up Monday, but I didn't bother building one due to the software problems. I decided to spend a little more time on it, and finally realized that the issue was with the debugger. My code was actually doing exactly what it was supposed to when observed externally, but the debugger was reporting something entirely different. After realizing this, I hurriedly finished up my remaining software tasks and then went to assemble a board. By the time I finished I had to get up for work in 4 hours, so I only made sure it powered up and could be programmed.

I couldn't wait to get home yesterday, because I was finally going to be able to put all the pieces together and test them in real-time in the car. And, I'm happy to report, everything worked exactly as it was supposed to!

What I have working so far:
  • Radio powers up with Chrysler splash screen when ignition is turned on
  • Screen dims/undims when headlight switch is turned
  • Display switches to camera input when car is put in reverse
  • All 6 steering radio switches work as they should
  • Displayed HVAC status (mode, temp, state, etc.) matches what's shown on the ATC head
I didn't have time yet to build the harness to plug it in where the radio is, plus I didn't want to pull anything out until I'm ready to mount the new one in case I want to take the car out. My testing now is just using a cable connected to the OBD port to get power and PCI. So, I couldn't test the audio functionality. But, it's just 4 pair of speaker wires, so I don't expect any issues there. When in reverse mode it shows a blank screen as I don't have a camera connected yet. I also don't expect any issues there.

Unfortunately, one thing I found is that it doesn't look like I can remove the ATC head entirely. It appears that it actually drives some of the logic for the auto functionality, and I can't differentiate between climate control messages from it and those from the BCM either. My plan around this is to put a custom board inside of the head that will connect to the existing circuit and have a connection to CAN as well. It will receive messages from the radio when a button is pressed on the climate screen, and it will then inject a signal into the controller in the ATC head to make it think one of its hard buttons was pressed. By doing this, I can hide the head in the dash or somewhere else. I've already prototyped this enough that I'm pretty confident it will work. I just need to take the time to lay out the board and get it made, and work on the software part while I'm waiting. If it works out OK, the last piece will be relocating the cabin temperature sensor from the front of the head since it will no longer be exposed to cabin air. I have an idea for that too.

I think my next immediate step will be finishing that harness so I can plug the radio in to the dash. I'll try to temporarily mount it along with a USB port and Sirius antenna while I decide my permanent plans for those. The ATC head will stay accessible until the new board is done and working. I also want to test the hands free. This radio is designed to use a rear view mirror with microphones, but the auto dim on that mirror won't work in the LH. It's possible the Town & Country mirror's microphones may work with this radio, but I'm not sure. So, to play it safe, I'm planning on using the 2018+ microphones. These mount in the headliner instead. Since I'm using a 2015 mirror microphone with my 2018 radio in my truck, I'm pretty sure they're interchangeable.

I wish I had some photos or video to accompany this wall of text, but I really don't. I didn't have enough hands to capture video while testing, and we've all seen what the radio looks like by itself. I will try to get something once the radio is sitting inside the car.
M-Pressive, Sneke_Eyez liked this
User avatar
 #378882  by Sneke_Eyez
 May 1st, 2019, 11:13 am
Very cool, Steve.

I am looking forward to seeing your progress on this project!
User avatar
 #378886  by LUNAT1C
 May 1st, 2019, 6:17 pm
I'm excited to see this project pan out. The only reason I have my Kenwood radio is to get the 5V RCA signal out to my system, and Android Auto/Apple CarPlay. My DSP can take a line-level signal from a factory radio, so I would be able to remove three sets of RCAs and run a single 8-way wire run from the radio to the DSP for my signal if push came to shove... but having a factory-looking radio is always ideal. Even better if it gets me a physical volume knob again. I still need to break out my iPad and program it, but currently my "volume knob" is simply a gain adjustment knob connected to my AudioControl DSP and mounted in the unused ash tray location of the center console. It will be programmed to control system-wide gain.

Definitely keep us apprised!
 #378892  by 00R/T
 May 1st, 2019, 11:19 pm
I just finished up the harness. It took me a bit longer than expected because I was working with new connectors I haven’t used before and had to get used to crimping them. I used the connectors that mate to the ones on the microphones so I can just plug them in directly now and test. Once they’re mounted, I’ll make extension cables to the size I need and everything should just plug in. I hate splicing anything, so I use factory connectors whenever possible. I’m not sure exactly what I’m doing for a camera yet, so I got the higher pin count version of the microphone connectors to use for the camera. Now all the wires for it are in a single plug, and I will just attach the mate to whatever I end up going woth.

Image

You can see that my module is kind of just dangling there at the moment. I designed an enclosure for it that I plan on 3D printing once I confirm I don’t need to make any changes to the board. The enclosure will attach to the harness with zip ties and that should keep the board protected.
Image

User avatar
 #378896  by In-trepid
 May 2nd, 2019, 7:20 am
Having seen a lot of this in person and having discussions about this when I delivered the car, I can say that this is a great undertaking and Steve has devoted a lot of time and thought to making this a reality for an LH car. I agree that a stock looking radio/HVAC /etc. control device that uses a modern interface is the way to go from a clean lines standpoint to allowing total functionality under the user's control. The implementation and programming is way above my level, but I have the utmost confidence that Steve will pull this off with his skills. I'm following and if any support is needed from my standpoint, don't be afraid to ask.
 #378897  by 00R/T
 May 2nd, 2019, 7:42 am
remi wrote: May 2nd, 2019, 3:37 amFollowing :)
I figured you would be. Now you know why I was asking you about the PCI bus messages. :D

I made a slight tweak to the software to remap the right center steering wheel button (audio advance) to the VR function. I don't think I've ever used that button in any of my vehicles, but I do use the VR button to invoke Siri fairly regularly. I think I will grab the microphones and the harness and test everything in place tonight. That way I'll know for sure that I have full functionality of the radio/media/phone portions and can focus all my attention on the ATC and then the heated seats.

One other thing that I still need to figure out is how the outside temperature is encoded on the PCI bus. It's a bit of a pain to begin with because it's not a values I can easily change and then watch the messages to make a correlation. I'm at the mercy of the actual ambient temp, and therefore have a limited sample set unless I hook up my computer and log the bus traffic multiple times a day. I'm pretty sure that I've figured out what message it is, but the decoding is odd. So far I've recorded 4 or 5 data points and I've found an equation that fits, but it's complicated and I can't understand where they got it from.
 #378898  by 00R/T
 May 2nd, 2019, 8:03 am
Here’s a proof of concept that I worked on a month or so ago. It doesn’t seem like a big deal that I replaced some buttons with different buttons, but the buttons I’m pressing aren’t connected directly to the ATC head. Rather, they’re acting as an input to an Arduino, and the Arduino is controlling the head in response to the button presses. This is important because it proves that I can control the head with an MCU, which means the triggering event can come from anywhere(a simple keypad like what’s shown, CAN bus, Bluetooth, etc.).

User avatar
 #378901  by LUNAT1C
 May 2nd, 2019, 10:42 am
I'm curious, this work is all being done on the 8.4 model radio. Is there any major difference between the 8.4 and 8.4N as far as integrating into a PCI bus car? Or when you say "8.4" are you referring to all models? Typically I would just use Android Auto and Google Maps, and that was my justification for getting a DDX Kenwood radio rather than a DNX model that cost several hundred dollars more, but it does have the limitation of not being able to navigate from the dash in Canada unless I get an expensive temporary upgrade on my Verizon plan. Had that situation last August when we went to Niagara with my parents, but my father upgraded my line and my mother's line so we could stay in contact when we weren't together and they could stay in contact with my sister back in Florida. Any time I've traveled in Canada otherwise I've simply used the Nokia HERE maps and navigation app, which lets me download various states and provinces to the phone and not rely on a data connection. This app is nice, but hasn't been ported to AA yet. Built-in nav would have solved that problem. Still not worth the money though since Google Maps worked if it got all the directions before leaving US towers. I had gotten all the way to gridlock on the QEW before I realized my phone was not on international data because I still had that blocked, and so it wasn't getting realtime traffic data to warn me or re-route me (too easy for the phone to jump on Canadian towers when we're on Belle Isle in the Detroit River, or somewhere on the riverwalk).
 #378902  by 00R/T
 May 2nd, 2019, 10:53 am
LUNAT1C wrote: May 2nd, 2019, 10:42 am I'm curious, this work is all being done on the 8.4 model radio. Is there any major difference between the 8.4 and 8.4N as far as integrating into a PCI bus car? Or when you say "8.4" are you referring to all models?
I'm speaking generally. There are 3 broad generations of the 8.4 system - the original Panasonic units in the 11-14 LX, Darts, I think maybe some Journeys; the Harman in the 13-17 RAM, 15-16 LX and others; and the current Panasonic that debuted in the 17 LX and then moved to RAM and others in 18. I think there is also some other variant they're using now in some Jeep models, but I don't know anything about that. On any vehicle with the PowerNet architecture, the messaging is mostly the same. There are some little idiosyncrasies between years (the latest generation radio won't allow control of heated/cooled seats in vehicles pre-16, for example), but everything is mostly compatible. For a given generation, the nav and non-nav versions are fully interchangeable.
 #378906  by 00R/T
 May 2nd, 2019, 6:45 pm
The more thorough in-car test is complete. It sounds excellent, and everything works, including my newly remapped VR button and the microphones. I was wondering what I’d do for the phone button I don’t have on my wheel, but a happy surprise when I asked the VR to make a call was “please press the phone button, or, would you like me to do it for you?” Why yes, yes I would!

IPod mode with headlights on to dim the too bright display in my too dim garage:
Image

The not-yet-functional but present seat heater controls:
Image

Going through some of the functions and testing the steering wheel buttons and shifter. It’s just playing static since no antenna is connected and I can’t play off my phone when recording video:


And, the ATC. It looks like it may be sending a fan speed of one or zero when transitioning, so I need to look into improving that. The new radio only has 7 speeds it can display while the car has 15, so i map 1-3 on the car to 1 on the radio and then 2 to 4 & 5, 3 to 6 & 7, up to 7 mapping to 14 & 15. When the head is hidden and I’m controlling from the radio, I’ll jump by 2 each increment so you won’t be able to set in between speeds and it’ll look fluid on the display.

Sonicrob liked this
User avatar
 #378907  by remi
 May 3rd, 2019, 3:26 am
00R/T wrote: May 2nd, 2019, 7:42 am I figured you would be. Now you know why I was asking you about the PCI bus messages. :D
Now I get it! If you want some more information feel free to ask. I found a few other projects on Github (basically an attempt to use an Arduino as DRBiii hardware with a custom software) that might help you.

I made a slight tweak to the software to remap the right center steering wheel button (audio advance) to the VR function. I don't think I've ever used that button in any of my vehicles, but I do use the VR button to invoke Siri fairly regularly. I think I will grab the microphones and the harness and test everything in place tonight. That way I'll know for sure that I have full functionality of the radio/media/phone portions and can focus all my attention on the ATC and then the heated seats.
00R/T wrote: May 2nd, 2019, 7:42 am One other thing that I still need to figure out is how the outside temperature is encoded on the PCI bus. It's a bit of a pain to begin with because it's not a values I can easily change and then watch the messages to make a correlation. I'm at the mercy of the actual ambient temp, and therefore have a limited sample set unless I hook up my computer and log the bus traffic multiple times a day. I'm pretty sure that I've figured out what message it is, but the decoding is odd. So far I've recorded 4 or 5 data points and I've found an equation that fits, but it's complicated and I can't understand where they got it from.
Have you tried running the "converter" function from the DRBDBReader project?
User avatar
 #378908  by remi
 May 3rd, 2019, 3:31 am
00R/T wrote: May 2nd, 2019, 7:42 am I figured you would be. Now you know why I was asking you about the PCI bus messages. :D
Now I get it! If you want some more information feel free to ask. I found a few other projects on Github (basically an attempt to use an Arduino as DRBiii hardware with a custom software) that might help you.
00R/T wrote: May 2nd, 2019, 7:42 am ...and can focus all my attention on the ATC and then the heated seats.
Well about that... If you have a chance, could you get into the 2004 ATC module and search for the Motorola MCU reference? I'm asking because from what I can tell about OTIS, they have custom references only. But the 3 EVIC I have around now have standard references (MC68HC908AS60). I ordered and received a ETL908 programmer so I should be able to dump the content of MC68HC908AS60 chips. If the ATC has a standard MCU reference, maybe you could reverse engineer the code to completely bypass the ATC.
00R/T wrote: May 2nd, 2019, 7:42 am One other thing that I still need to figure out is how the outside temperature is encoded on the PCI bus. It's a bit of a pain to begin with because it's not a values I can easily change and then watch the messages to make a correlation. I'm at the mercy of the actual ambient temp, and therefore have a limited sample set unless I hook up my computer and log the bus traffic multiple times a day. I'm pretty sure that I've figured out what message it is, but the decoding is odd. So far I've recorded 4 or 5 data points and I've found an equation that fits, but it's complicated and I can't understand where they got it from.
Have you tried running the "converter" function from the DRBDBReader project?
 #378911  by 00R/T
 May 3rd, 2019, 9:07 am
remi wrote: May 3rd, 2019, 3:31 am Now I get it! If you want some more information feel free to ask. I found a few other projects on Github (basically an attempt to use an Arduino as DRBiii hardware with a custom software) that might help you.
Thanks. I found a bunch of stuff too. I'll have to revisit it if I get stuck.
remi wrote: May 3rd, 2019, 3:31 am Well about that... If you have a chance, could you get into the 2004 ATC module and search for the Motorola MCU reference? I'm asking because from what I can tell about OTIS, they have custom references only. But the 3 EVIC I have around now have standard references (MC68HC908AS60). I ordered and received a ETL908 programmer so I should be able to dump the content of MC68HC908AS60 chips. If the ATC has a standard MCU reference, maybe you could reverse engineer the code to completely bypass the ATC.
Sure. I don't know what year the one I have hacked apart is from as it was sitting in my parents' basement from probably 10 years ago, but I'll take a look. I do know that it uses off-the-shelf Motorola power supply and OKI VFD ICs as I looked those up already.
remi wrote: May 3rd, 2019, 3:31 am Have you tried running the "converter" function from the DRBDBReader project?
I haven't, but I actually just figured it out. I remember the guy who put that together saying that a lot of the data was in standardized formats, so I spent the morning crawling through the various volumes of the SAE J2178 standard. It turns out the temperature is defined by that standard, so I now have my transfer function!