As described in wiring the iBooster you can already use it in failsafe mode. However, it might even be more interesting to use advanced features via the CAN-BUS or even CAN control the iBooster. The latter can be interesting from DIY autonomous driving projects for example with OpenPilot by comma.ai. Join the quest for reverse engineering the iBooster CAN-BUS.
Unfortunately the CAN-BUS details of the iBooster are not publicly available (as far as I know) and I have not been able to find .dbc files covering the data. So it is a process of sniffing and decoding to hopefully find all ins and outs. Use at your own risk!
2x iBooster CAN-BUS
The iBooster is a dual CAN device. Both channels have no termination and run at 500 kbps.
- Vehicle CAN (CAN-H = pin 25 / CAN-L = pin 16 on the iBooster ECU)
- YAW (CAN-H = pin 18 / CAN-L = pin 10 on the iBooster ECU)
Did some CAN-BUS sniffing on the bench with my Peak CAN adapter and SavvyCAN.
In a short while I’ll hook up my brand new CANedge1 too, but I still need to make cables. I’m becoming a reseller so drop me a line if you want one too. CSS Electronics has some great visualization and logging over time tools.
Deciphering iBooster CAN
Previously this post contained the findings of just sniffing the CAN-BUS. While working on this together with Jon (@tesla_bimmer on Insta) he pointed me towards a huge pile of .dbc files in the DCBTools project. A pot of gold I’d say. Below you can find the ones for Tesla:
Sniffing vehicle CAN
I’ve used the tesla_models.dbc and on the vehicle CAN I’d did get some proper interpretations. Brake input stroke in mm via CAN!
This can be useful to improve regenerative braking in a conversion.
Traditionally a pressure transducer is used to know the driver hits the brakes. That signal is then used in the vehicle control unit (VCU) to also activate regenerative braking. The advantage of using a CAN input based on stroke is that it is faster. You can immediately (gradually) increase regenerative braking and don’t have to wait for pressure buildup. Additionally it can be used to overrule any throttle input.
Sniffing YAW CAN
On the YAW CAN-BUS only two messages are being send, 0x38E and 0x38F. While pushing in the rod on the YAW CAN-BUS I did get some consistent results. It looks like Byte 3 of message 0x38E represents the push rod position. Unfortunately these ID’s are not in the .dbc’s I have. Jon has figured this out (it’s not only Byte 3).
The output with the push-rod in IDLE position is 0x40 (so 64 decimal) and when fully pressed the value is 0xC0 (192 decimal). Potentially this value can be used to trigger regenerative braking. The only thing is that it does not tell us how hard someone it pressing the pedal. Furthermore the value range will depend on the brake pad travel and will be different on every car. However from a deviation from IDLE position you do know the brake is being pressed.
More sniffing? Playback?
So what’s next? This is as much as I can do for now with my set of skills, tools and hardware. Think it would be beneficial to get CAN data from a driving Tesla. The vehicle CAN of the iBooster should be available on the diagnostics port. Once I get my hands on such a log, I can do a playback to the booster and see whether we can get it to work on the bench.
If you have any ideas or input on how we can move forward, please drop me a line. If someone for example already has a CAN-BUS log of a Tesla Model S, I could do a playback and see what happens and eliminate rows from the playback to find out what CAN ID’s are inputs for the iBooster.
If someone is intterested in the logs I made from the two busses, let me know and I can share them.
Looking forward to hearing from you! You can contact me via e-mail.
Blog series on power brakes
- Vacuum assisted power brakes
- Electric power brakes
- Installing the iBooster
- Wiring the Tesla iBooster
- Performance test of the Tesla iBooster
- CAN control of the iBooster
- Other donor vehicles for the iBooster
Disclaimer/warning that is not only valid for this article but applies in general.
It is the sole responsibility of the person or company selecting or installing any component or kit in any car modification or upgrade (like brakes, drivetrain, etcetera) to determine the suitability of the component or kit for that particular application. Especially when using parts or components that were not directly designed for use in that specific brand or model. If you are not sure how to safely use a part, component or kit, you should not install or use it. Do not assume anything. Inspiration and information found on this website, elsewhere or examples that others are using a part, component or kit does not guarantee proper installation or match with your particular setup.
8 thoughts on “iBooster CAN-BUS research”
Very nice posts Lars!
For those of you who don’t know I’m working on a Citroën Acadiane EV conversion project where I want to add AutoPilot like functions with an open source self drive model called OpenPilot.
I fitted the iBooster from a Chevy Volt for electric braking support.
I don’t know if the Tesla iBooster uses the same CAN messages but maybe it helps.
This is some of my research about the CAN communication with the iBooster:
# information about the openDBC file format can be found here:
# Chassis CAN on pin 16,25 & 15,24
# information from: https://github.com/commaai/opendbc/blob/master/gm_global_a_chassis.dbc
# IBOOSTER is the EBCM (Electronic Brake Control Module);
# VCU is the (Vehicle Control Unit)
# this message is probably needed to make the pedal feel harder when regen is used for deceleration ???
BO_ 560 iBoosterRegen: 6 VCU
SG_ Regen : 1|10@0+ (1,0) [0|0] “” IBOOSTER
# this is the status of the iBooster with the FrictionBrakePressure.
# maybe some other parameters in this message which are not documented jet.
BO_ 368 iBoosterFrictionBrakeStatus: 8 IBOOSTER
SG_ FrictionBrakePressure : 23|16@0+ (1,0) [0|0] “” VCU
# this is the friction brake comand for the iBooster
BO_ 789 iBoosterFrictionBrakeCmd: 5 VCU
SG_ RollingCounter : 33|2@0+ (1,0) [0|0] “” IBOOSTER
SG_ FrictionBrakeMode : 7|4@0+ (1,0) [0|0] “” IBOOSTER
SG_ FrictionBrakeChecksum : 23|16@0+ (1,0) [0|0] “” IBOOSTER
SG_ FrictionBrakeCmd : 3|12@0- (1,0) [0|0] “” IBOOSTER
# Powertrain CAN on pin 10,18 & 11,19
# information from: https://github.com/commaai/opendbc/blob/master/gm_global_a_powertrain.dbc
BO_ 189 iBoosterRegenPaddle: 7 IBOOSTER
SG_ RegenPaddle : 7|4@0+ (1,0) [0|0] “” VCU
BO_ 209 iBoosterBrakePedalTorque: 7 IBOOSTER
SG_ BrakePedalTorque : 3|12@0+ (1,0) [0|0] “” VCU
BO_ 241 iBoosterBrakePedalPosition: 6 IBOOSTER
SG_ BrakePedalPosition : 15|8@0+ (1,0) [0|255] “” VCU
# More information about how the CAN messages for recuperative braking and friction braking are created can be fount here
# check create_friction_brake_command…
I’m fascinated by the notion of using an iBooster and EPAS to retrofit adaptive cruise and lane-keeping to a classic car. If you have a build blog somewhere, I’d love to read more about your project.
You can follow his project on Instagram @minoseigenheer.
Info on Openpilot and the DIY adaptive cruise control etcereta can be found on comma.ai.
thanks a lot for the Infos about the ibooster so far!
We would like to use the ibooster for a remote controlled electric vehicle project.
Did anyone already manage to get the ibooster to work on can-input only? Did you already try to contact Bosch directly for advice (at least it’s worth a try I guess ^^)?
Best regards, Dominik
Myself I have not been able to spend more time on it. I’ve heard that Comma.ai is quite far along in adding iBooster support in their Panda.
Some details can be found on their Github: panda / board / ibst
Furthermore I know Seb Smith has solved the puzzle and is able to control the iBooster and is working on some kind of controller for that. Have not seen it being announced to no public info to link. So I guess it is still in development.
Will keep updating this blogpost as more information and possibilities become available.
Seb’s controller (and different levels of kit) are now available here: https://sghinnovations.com/?product=ibooster-controller-ecu
Hello! Thank you for responding to my last post. I was also curious if you can program the “pedal feel” into this unit?
Unfortunately not that I am aware of. So it is a matter of finding the right balance between fluid displacement, master cilinder bore and brake pedal linkage design.