Bluetooth that actually works...
To make the experience fit your profile, pick a username and tell us what interests you.
After a bit of break from the project Im back into it.
The Bluetoooth Module The Microchip RN52 has arrived along with a few MCP2515 based CAN interfaces fro testing.
Ive just set up a test bed Raspberry Pi with MC2515 adaptor attached (what I Was suing to talk to the car originally - this allows me to display can Messages via CANdump and send send comands individualy with CANsend or send a log file with CANplayer.
To Bring up CAN interface on the pi need to
sudo /sbin/ip link set can0 up type can bitrate 125000
For the time beign Ill be using a UNO clone and MCP2515 module for the busines end.
The UNO is connected to the MCP2515 board
Ive settled on using the RN52 Bluetooth module from Microchip which arrived this week. I have been using Eagle for all my schematic capture and PCB work for some time but decided NOW was the time to change over to KiCAD...
So far I have succesfully created the component for the schematic and now working on the foot print - its always fun leaning a new system LOL. Im sure it will keep me busy for at least a few days :lol:
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.
Become a member to follow this project and never miss any updates