I've been trying to get a working canbus box to use a chinese android head unit with daughters 207. But it seems after trying several canbus boxes the older pre 2008 cars are not covered.
This is because it was in the switchover era between their proprietory VAN bus (206, 207 for certain markets only), and later CANBUS based systems.
Also the RD4 radio I removed was deeply integrated and used to configure the clock, set settings and access some menus on the in car display.
I got fed up of it all and decided to do something about it. Im documenting this here as another example of diy'ing stuff for a car with a proprietory canbus.
First there's signals in the quadlock connector we can tap into for this in part A of the connector to the audio head unit. +12v and gnd for power, and CANH and CANL on pins 10 and 13.
I made a layout on vero/proto board to hold a buck-boost converter module to convert the 12v of the vehicle to 5v, a Esp32 dev board, SN65HVD230 canbus board designed with interfacing small microcontrollers like ESP32 and arduino to CAN buses in mind and a fuseholder. I will make a nice pcb in KICAD and 3d print a case for it and choose a smaller buckboost module when its all working and tested (probably, maybe, the best intentions and all that...)
I also added lead tails to the canbus connections on the pcb so I could plug in my oscilloscope and logic analyser to get more insight. Logic Analyser sounds fancy and expensive, but its a 11e Saleae clone off ali express that I use under linux with Sigrok + Pulseview.
The ultimate aim is to leave the ESP32 board in the car, and have it communicate the stalk data up to the headunit via a serial interface the chinese android boxes have, in a format the headunit speaks properly.
It doesnt even have to be the same car since we can remap it to whatever ID we feel like on the fly, just has to be a supported one in the head unit.
Behold the device named "GiraffeBasedViolence" for some obscure reason probably involving hardly any sleep and fatigue, before it was swaddled with kapton tape to stop shorts in the dash cavity.
Using this and the saleae, after a hiccup caused by the CAN board having its own termination resistor was resolved bydesoldering and putting the unneeded extra terminating resistor in the bin once i found it, I was able to get CAN frames out the car itself.
Pulse view is linux open source software, and great for this kind of thing. The CANL & CANH pins of the can interface board are on channels d2/d3. So I added a can Decoder to these to see traffic after setting parameters around bitrate/frequency etc.
Fast forward in hours spent pouring over can traffic dumps, identifying which can ID carried the stalk data if any, and likely candidates for other potentially interesting stuff (car door open, lights on, reversing etc) I wrote a dumper for the ESP32 in C using the espresive framework, flashed it the esp32 and started to capture traffic directly on that.
After some iterations, I ended up with this narrowed in to listen for only the stalk frames now identified as being on CAN ID 0x21F, and print their human names on the monitor channel.
The code is somewhat documented, but I had some late nights doing it so if it doesnt make sense somewhere thats not that surprising :
github.com
Running that and monitoring it with my laptop I was greeted with lots of nice information each time a stalk control was pressed.
I (...) PSA207_STALK: STALK baseline t=69771ms id=0x21F dlc=3 raw=00 00 00
I (...) PSA207_STALK: STALK volume_up t=82780ms id=0x21F dlc=3 raw=08 00 00
I (...) PSA207_STALK: STALK volume_down t=100673ms id=0x21F dlc=3 raw=04 00 00
I (...) PSA207_STALK: STALK next_track t=411687ms id=0x21F dlc=3 raw=80 00 00
I (...) PSA207_STALK: STALK prev_track t=139794ms id=0x21F dlc=3 raw=40 00 00
I (...) PSA207_STALK: STALK source t=160809ms id=0x21F dlc=3 raw=02 00 00
I (...) PSA207_STALK: STALK scroll_up t=186383ms delta=1 pos=1 raw=00 01 00
I (...) PSA207_STALK: STALK scroll_down t=207298ms delta=-1 pos=4 raw=00 04 00
So there we have it at its current state, we can read the CAN frames from the stalk buttons on about 20 quids worth of hardware, and assign them friendly names in the logs.
Currently thats not that useful, but next step coming when I have time, is writing a extra bit of code that runs on the ESP32, and hooking it up to the serial port interface (SPI) on the back of the chinese android head unit.
The plan is to emulate a later car's can frames, and map them to the ones above inside the ESP32. I might get fancy and make button combos and other features but right now having a working joystick on the steering wheel control the stereo would be great.
There is also another facet to the RD4 head unit thats deeply integrated. The setting of the vehicle clock.
If you dont set the clock, the car's display flashes the time annoyingly on all the menus. Its not even possible to set it with diagbox and the low level diagnostic hardware, it has to be via buttons on the RD4 head unit.
It was doing this when we picked up the car, but I ignored it since we were planning an android head unit from the start.
I put the original RD4 in to set the clock as part of this, and it didnt work. Some more investigation has revealed that the radio itself has to be coded with the vehicles VIN before it is accepted as trusted.
I think this is why I cant access the clock menu to set time, because it would mean the BSI accepting input from a untrusted device on the bus, which is a hacking vector.
Tomorrow I'm going to recode the RD4 with the correct vin for the car and if it actually works and can set the clock I'll take a logic analyser dump of the process and see if I can work out how to get the esp32 accepted as a trusted device to do the same.
If I can capture the process and reverse it enough to replicate, I'll implement it in code and make a captive portal web interface right on the esp32 itself, that we can connect to with a phone to finally set the clock from.
The main problem is I only get 1-2 days to work on iterations when daughter's home from uni in her car. So to be continued. Good fun though...
This is because it was in the switchover era between their proprietory VAN bus (206, 207 for certain markets only), and later CANBUS based systems.
Also the RD4 radio I removed was deeply integrated and used to configure the clock, set settings and access some menus on the in car display.
I got fed up of it all and decided to do something about it. Im documenting this here as another example of diy'ing stuff for a car with a proprietory canbus.
First there's signals in the quadlock connector we can tap into for this in part A of the connector to the audio head unit. +12v and gnd for power, and CANH and CANL on pins 10 and 13.
I made a layout on vero/proto board to hold a buck-boost converter module to convert the 12v of the vehicle to 5v, a Esp32 dev board, SN65HVD230 canbus board designed with interfacing small microcontrollers like ESP32 and arduino to CAN buses in mind and a fuseholder. I will make a nice pcb in KICAD and 3d print a case for it and choose a smaller buckboost module when its all working and tested (probably, maybe, the best intentions and all that...)
I also added lead tails to the canbus connections on the pcb so I could plug in my oscilloscope and logic analyser to get more insight. Logic Analyser sounds fancy and expensive, but its a 11e Saleae clone off ali express that I use under linux with Sigrok + Pulseview.
The ultimate aim is to leave the ESP32 board in the car, and have it communicate the stalk data up to the headunit via a serial interface the chinese android boxes have, in a format the headunit speaks properly.
It doesnt even have to be the same car since we can remap it to whatever ID we feel like on the fly, just has to be a supported one in the head unit.
Behold the device named "GiraffeBasedViolence" for some obscure reason probably involving hardly any sleep and fatigue, before it was swaddled with kapton tape to stop shorts in the dash cavity.
Using this and the saleae, after a hiccup caused by the CAN board having its own termination resistor was resolved bydesoldering and putting the unneeded extra terminating resistor in the bin once i found it, I was able to get CAN frames out the car itself.
Pulse view is linux open source software, and great for this kind of thing. The CANL & CANH pins of the can interface board are on channels d2/d3. So I added a can Decoder to these to see traffic after setting parameters around bitrate/frequency etc.
Fast forward in hours spent pouring over can traffic dumps, identifying which can ID carried the stalk data if any, and likely candidates for other potentially interesting stuff (car door open, lights on, reversing etc) I wrote a dumper for the ESP32 in C using the espresive framework, flashed it the esp32 and started to capture traffic directly on that.
After some iterations, I ended up with this narrowed in to listen for only the stalk frames now identified as being on CAN ID 0x21F, and print their human names on the monitor channel.
The code is somewhat documented, but I had some late nights doing it so if it doesnt make sense somewhere thats not that surprising :
GitHub - jmp49152/PSA-207-ESP32-Stalk-Decoder: Quick and dirty esp32 project to read the Stalk CAN frames off a 2007 207 Quadlock socket, and output human friendly events when they occur as diagnostics.
Quick and dirty esp32 project to read the Stalk CAN frames off a 2007 207 Quadlock socket, and output human friendly events when they occur as diagnostics. - jmp49152/PSA-207-ESP32-Stalk-Decoder
github.com
Running that and monitoring it with my laptop I was greeted with lots of nice information each time a stalk control was pressed.
I (...) PSA207_STALK: STALK baseline t=69771ms id=0x21F dlc=3 raw=00 00 00
I (...) PSA207_STALK: STALK volume_up t=82780ms id=0x21F dlc=3 raw=08 00 00
I (...) PSA207_STALK: STALK volume_down t=100673ms id=0x21F dlc=3 raw=04 00 00
I (...) PSA207_STALK: STALK next_track t=411687ms id=0x21F dlc=3 raw=80 00 00
I (...) PSA207_STALK: STALK prev_track t=139794ms id=0x21F dlc=3 raw=40 00 00
I (...) PSA207_STALK: STALK source t=160809ms id=0x21F dlc=3 raw=02 00 00
I (...) PSA207_STALK: STALK scroll_up t=186383ms delta=1 pos=1 raw=00 01 00
I (...) PSA207_STALK: STALK scroll_down t=207298ms delta=-1 pos=4 raw=00 04 00
So there we have it at its current state, we can read the CAN frames from the stalk buttons on about 20 quids worth of hardware, and assign them friendly names in the logs.
Currently thats not that useful, but next step coming when I have time, is writing a extra bit of code that runs on the ESP32, and hooking it up to the serial port interface (SPI) on the back of the chinese android head unit.
The plan is to emulate a later car's can frames, and map them to the ones above inside the ESP32. I might get fancy and make button combos and other features but right now having a working joystick on the steering wheel control the stereo would be great.
There is also another facet to the RD4 head unit thats deeply integrated. The setting of the vehicle clock.
If you dont set the clock, the car's display flashes the time annoyingly on all the menus. Its not even possible to set it with diagbox and the low level diagnostic hardware, it has to be via buttons on the RD4 head unit.
It was doing this when we picked up the car, but I ignored it since we were planning an android head unit from the start.
I put the original RD4 in to set the clock as part of this, and it didnt work. Some more investigation has revealed that the radio itself has to be coded with the vehicles VIN before it is accepted as trusted.
I think this is why I cant access the clock menu to set time, because it would mean the BSI accepting input from a untrusted device on the bus, which is a hacking vector.
Tomorrow I'm going to recode the RD4 with the correct vin for the car and if it actually works and can set the clock I'll take a logic analyser dump of the process and see if I can work out how to get the esp32 accepted as a trusted device to do the same.
If I can capture the process and reverse it enough to replicate, I'll implement it in code and make a captive portal web interface right on the esp32 itself, that we can connect to with a phone to finally set the clock from.
The main problem is I only get 1-2 days to work on iterations when daughter's home from uni in her car. So to be continued. Good fun though...
