Bluetooth that actually works...
To make the experience fit your profile, pick a username and tell us what interests you.
Now Ive sorted the require codes I can actually move onto making the project a reality....
Bluetooth will be handled by the Microchip RN52 module which as far as I can tell allows for both microphones already installed in the car to be used and should have sufficient output drive to drive the input to the headunit without any further analog circuitry. This just simplifies and reduces the component count.
The micro to drive it could pretty well be anything I could go down the Arduino route but I dont care much for adding to many "modules" and woul dprefer a more integrated solution, yes I could get a chip and just use it or I could go back to my roots and use a PIC....
I just need something that can send a few commands over SPI to the Can driver which will be doing all the CAN bus heavy lifting, there is no signifcant timing constraints so pretty well anything that can handle SPI would be suitable.
After some trial an error and late nights sitting in the car trying different codes I think I have come to a point where I can start on the firmware for the module.
To turn the head unit to Phone mode is as simple as sending
where x is the cellular signal strength (1-5)
y is the phone battery level (1-5)
If x or y is set to F then the applicable icon is not displayed.
To exit phone mode sending
Two 14 character lines of text can be displayed by sending
line 1 3F5#05xxxxxxxxxxxxxx
line 2 3F5#15xxxxxxxxxxxxxx
3F5#13xxxxxxxxxxxxxx (x is the ascii code for the text)
just looking back through my notes it appears i got stuck into this back on the 3rd of November - now 6 weeks later all Ive got to show for it is a couple of CAN ids ... its a bit depressing .... hopefully in 6 weeks time ill have something more substantial to show...
I had previously determined the format for sending text to the head unit but I had noticed despite been able to activate the Uconnect and connect to it via bluetooth I noticed with it sitting on the bench It was not sending the text to for the headunit.
I figured there must be some response from the headunit once it recived the request to switch to phone mode.
I took log from the car for a phone call and loctated the "Connect" text 3f5# and searched back in the log for the "switch to phone mode" 2d0#82 and played that to the Uconnect module and next time I made a call the text was been sent.
pruning the log down by 1/2 and replaying the log untill I was down to a only a few lines and then took a couple of stabs in the dark and nailed it with
I dont know the format but that data string gets the job done :)
It appears that the Uconnect module doesnt care when the string is sent but at least I can now look out for it and use it as a check to make sure I have succesfully connected to the headunit.
Just had a quick look at some logs I had taken first thing in the morning when my battery would have been fully charged and it looks like the 4th byte is the Battery Level
F5 fully charged
F3 half charged
as my phone has been between 55% and now 43% while testing this evening that fits neatly into a 5 Bar display. I expect to see the 4th Byte drop to F2 once my phone drops below 40%
Ran phone with the "torch" on and played a few you tube clips and got it below 40% and "Bingo" that 4th byte dropped down to F2 as expected.
Thats a bit of success for the evening, got signal strength and Battery level determined.
Spent some time this evening looking at the response from the Uconnect module.
The module responds at various times with ID's
doing a quick comparison between starting up the uconect with a phone nearby with Bluetooth on and off indicated that 2D0 correlated to a bluetooth connection.
Upon a bluetooth connection the Uconnect transmits
2D0#F0E022FF01 2D0#F0E022F301 2D0#F0E022F301 2D0#F1E022F301 2D0#E1E022F301 2D0#E1E022F301
the E1E022F301 is repeated every second.
Interestingly the 3rd Byte in this case 22 appears to represent the mobile phone signal strength
21 == 1 Bar
22 == 2 Bar
23 == 3 Bar
I was not able to verify but suspect 24 would be 4 bars
I did notice a couple of occasions of 2F and that was after wrapping the phone in aluminum foil - I suspect this indicates no signal.
I could not determine any indication of battery level but I only had a 10% variation on the phone during the time I had to test so perhaps the battery level reported by the Uconnect is to granular to show up in my short test.
After a lot of trial and error Ive got the Uconnect to activate with just one command repeatedly sent every 100ms.
I created a txt file (Ucconect.txt) containing the following
(1607033557.000000) can0 208#00A2090000002D (1607033557.100000) can0 208#00A2090000002D (1607033557.200000) can0 208#00A2090000002D (1607033557.300000) can0 208#00A2090000002D (1607033557.400000) can0 208#00A2090000002D (1607033557.500000) can0 208#00A2090000002D
using canplayer to repeatedly play the file
canplayer -I Ucconect.txt -l i -v
It takes aproximately 30 seconds for a connection to the phone to be established.
#NOTE: the Ucconect module is configured via voice commands - I had previously paired the phone while the uconnect module was installed in the car.
The next step will be to identify the codes sent when the ucoonect setup button is pressed on the head unit. That in conjunction with the addition of a microphone and earphone should allow me to configure the Uconnect while on the bench.
I am hoping to use the uconnect button to initiate the pairing function on my new and improved Bluetooth interface with out the rather inept voice control.
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
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
From the table in the previous Log it appears that the Uconnect module sends a
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
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.
Become a member to follow this project and never miss any updates