Bluetooth For 2008 Chrysler Grandvoyager

Taking gut feeling guesses as to which IDs to remove was taking too long so I upped the risk and removed all IDs starting with 2 !

This had the end result of no Bluetooth connection - This is good as now I can concentrate on the 2xx IDs.

The Ultimate aim is to build a bluetooth device that will switch the headunit to the phone input which is done over the CAN bus it is necessary to work out what signals turn on the unit and what is required to keep it alive and active and what data is required to be sent to the headunit and how the headunit responds.

So Ive pulled the Ucconect module from the car and am attempting to get it to work sitting on the bench connected to a raspberry pi.

I have taken a log from the car and deleted all the commands I believe originate from the Uconnect module and played it back from the Pi.

The Uconnect module succesfully starts up and automatically connects to my phone.

There is some 200 messages a second in the log and Im pretty sure most of them are irrelevant for the Uconnect module, which leads to the question "What codes can I get rid of?"

Thanks to the work of BiggRanger https://github.com/BiggRanger/CANBUS-Vehicle-Reverse-Engineering

I have a starting point of thingsto get rid of so far I have successfuly eliminated the need for

211, 214, 217, 219, 3A3, 3A2, 516, 20E.

I pulled the Uconnect module from the car to experiment with what it takes to turn it on and what it responds with - I dont want to be sending unecesarry data on my bus.

Basic set up is Uconnect module - MCP2515 - Rasp Pi.

I had determined a wide variety of commands would ilicit a response from the Uconnect I couldnt get it to stay on and make a bluetooth connection to it. So I tried playing a log I had made from the car to see how it would respond and found using canplayer to be somewhat frustrating I could only send a few commands before the player would terminate and return

sendto: No buffer space available

A bit of searching turned up lots of "theories" but the solution appeared in the canutils gitub repository

https://github.com/linux-can/can-utils/issues/40

with the solution been to increase the TX queue length

sudo ifconfig can0 txqueuelen 1000

 doing that allowed me to send a big log file to the module and I could succesfully conect via bluetooth iteretsingly though despite the succesfull connection I noticed a lack of description data been sent "Connecting Phone" and the time of call

the following expected sequence is missing

• 3F5#05436F6E6E656374
• 3F5#0269E6720202020
• 2D0#82F124F501

From the table in the previous Log it appears that the Uconnect module sends a

2D0#E0E024F501

2D0#82F124F501

to switch the Head unit to Phone Mode.

I tried doing a can send of those commands and confirmed the HeadUnit would switch to phone mode but would drop back to the radio rather quickly, I suspect the regular transmission of 2D0#F0E02FFF01 is a heartbeat from the Uconnect module also indicating that it is not active.

I added a power switch to the Uconect module so I could turn it on and off effectively removing it from the system.

Turning the Uconnect off and sending the 2D0#E0E024F501 #82F124F501 would switch the HU to Phone mode after about 30 seconds the HU would swicth back to radio. Sending 84F124F501 periodically once in Phone mode would keep the mode active. Sending a 3F5 appeared to send text to the HU which would be buffered untill the next 2D0 when it would be written to the Display.

The display will show a line of Text indicating the elapsed time of the call and at the bottom of the screen it shows the phone battery level and signal strength.

the 3F5 appears to be just the text line in HEX format 8 bytes at a time. Longer words can be displayed by sending multiple 3F5#data prior to the next 2D0#.

ie "Connecting" is displayed by sending

• 3F5#05436F6E6E656374
• 3F5#0269E6720202020
• 2D0#82F124F501

As far as I can tell at this stage the format of the 3F5 id consists of 8 bytes the first byte I haven't worked out yet and the next 7 bytes are 7 characters.

Todo

• Determine the purpose of the first Byte of the 3F5 ID
• Determine the format of the 2D0 ID

Watching the Cansniffer output while making a phone call I noticed along with the 3F5 id 2D0 also popped up at the start of the call. I spent some time loking at the Candump Logs I had taken and noted filtering out the everything but 3f5 and 2D0 a pattern become evident.

After not getting anywhere with the 0x3F5 ID although it is related (sends display information to the Head Unit - there had to be some other related ID that switched the head unit.

Thanks to the work done by BiggRanger I was able to use the time ID 0x3E6 as a reference to refine the point at which I activated a phone call and could look back from the 0x3F5 "Connect" string a few seconds.

The amount of data on the bus is quiet a lot even when the ignition is just in the accessory position and nothing being activated there is around 200 messages a second.

Been working on ways to gather the data from the CAN bus t work out what happens when I make a call on my phone.

Ive put together an Arduino and MCP2515 module to connect t the CAN bus to dump data and see whats going on.

Basic set up is

Arduino Clone connected to MCP2512_CAN module which gets connected to the CAN bus via a couple of wires I soldered to the CAN bus lines inside the Uconnect module. This was the easiest way for me to get access to the bus but now means I cant disconnect the Uconnect module and continue to monitor the bus. Thinking of putting a power switch in the Uconnect module to be able to turn it on and off easily.

Ive tried a coupl eof methods to retrieve the Bus data -

1.  Serial capture of traffic.
2.  Arduino Sketch to loosely emulate the Lawicel CAN adaptor https://github.com/latonita/arduino-canbus-monitor.
3. attach the MCP2515 board directly to a raspberry pi and SSH into it from the laptop and capture data

1 gave me results but didnt look right so I moved onto number 2 and was bale to extract a lot of data which gave me results that matched data I had foind posted on line https://github.com/BiggRanger/CANBUS-Vehicle-Reverse-Engineering

But I was unable to send data on the bus.

So investigating why I could send data I gave the Raspberry pi a shot and was able to recive and send data though at a more complex set up as I have to power the Pi from mains connect it to the car and SSH in from my laptop to retrieve the data. A bit more complex BUT it does allow me to send data on the BUS. Ill come back to the Arduino issues at a later date.

After recording a few logs and looking through the data along with a bit of guidance from the BiggRanger repository I have noticed when a call is made by a paired phone a series of messages under ID 3F5 appear on the Bus. Unfortunately I am unable to ascertain where the messages originate .

3F5 includes the HEx representation of Connecting Phone and then the time the call has been going. I have tried replaying these commands but there is no change in the response from the headunit .

The factory Uconnect system has sends Audio (left and Right) to the head unit and connects to the CAN bus @ 125Kbps. Depending on the year of manufacture this speed can very, but thats what it is for my application.

Given the only connection to the headunit is via the Can bus I am starting with the presumption that the head unit sends control signals via CAN to the Uconnect module which then sends the audio to the Headunit.

Step 1. Monitor the can bus and determine the control signals required to turn on the Uconnect module and initiate the blue tooth.

To do this I have put together an arduino Uno with a MCP2515 CAN module, hooked into the CAN bus and log some data.