8c77a5df20 | ||
---|---|---|
generated | ||
generator | ||
.gitignore | ||
README.md | ||
__init__.py | ||
acura_ilx_2016_nidec.dbc | ||
acura_rdx_2018_can.dbc | ||
ford_cgea1_2_bodycan_2011.dbc | ||
ford_cgea1_2_ptcan_2011.dbc | ||
gm_global_a_chassis.dbc | ||
gm_global_a_lowspeed.dbc | ||
gm_global_a_lowspeed_1818125.dbc | ||
gm_global_a_object.dbc | ||
gm_global_a_powertrain.dbc | ||
honda_accord_touring_2016_can.dbc | ||
honda_civic_hatchback_ex_2017_can.dbc | ||
honda_clarity_hybrid_2018_can.dbc | ||
honda_crv_ex_2017_can.dbc | ||
honda_pilot_touring_2017_can.dbc | ||
hyundai_2015_ccan.dbc | ||
hyundai_2015_mcan.dbc | ||
hyundai_i30_2014.dbc | ||
mercedes_benz_e350_2010.dbc | ||
subaru_outback_2016_eyesight.dbc | ||
tesla_can.dbc | ||
toyota_iQ_2009_can.dbc | ||
toyota_prius_2017_adas.dbc | ||
vw_golf_mk4.dbc | ||
vw_mqb_2010.dbc |
README.md
opendbc
The project to democratize access to the decoder ring of your car.
DBC file basics
A DBC file encodes, in a humanly readable way, the information needed to understand a vehicle's CAN bus traffic. A vehicle might have multiple CAN buses and every CAN bus is represented by its own dbc file. Wondering what's the DBC file format? Here a good overview.
How to start reverse engineering cars
opendbc is integrated with cabana.
Use panda to connect your car to a computer.
Good practices for contributing to opendbc
-
Comments: the best way to store comments is to add them directly to the DBC files. For example:
CM_ SG_ 490 LONG_ACCEL "wheel speed derivative, noisy and zero snapping";
is a comment that refers to signal
LONG_ACCEL
in message490
. Using comments is highly recommended, especially for doubts and uncertainties. cabana can easily display/add/edit comments to signals and messages. -
Units: when applicable, it's recommended to convert signals into physical units, by using a proper signal factor. Using a SI unit is preferred, unless a non-SI unit rounds the signal factor much better. For example:
SG_ VEHICLE_SPEED : 7|15@0+ (0.00278,0) [0|70] "m/s" PCM
is better than:
SG_ VEHICLE_SPEED : 7|15@0+ (0.00620,0) [0|115] "mph" PCM
However, the cleanest option is really:
SG_ VEHICLE_SPEED : 7|15@0+ (0.01,0) [0|250] "kph" PCM
-
Signal's size: always use the smallest amount of bits possible. For example, let's say I'm reverse engineering the gas pedal position and I've determined that it's in a 3 bytes message. For 0% pedal position I read a message value of
0x00 0x00 0x00
, while for 100% of pedal position I read0x64 0x00 0x00
: clearly, the gas pedal position is within the first byte of the message and I might be tempted to define the signalGAS_POS
as:SG_ GAS_POS : 7|8@0+ (1,0) [0|100] "%" PCM
However, I can't be sure that the very first bit of the message is referred to the pedal position: I haven't seen it changing! Therefore, a safer way of defining the signal is:
SG_ GAS_POS : 6|7@0+ (1,0) [0|100] "%" PCM
which leaves the first bit unallocated. This prevents from very erroneous reading of the gas pedal position, in case the first bit is indeed used for something else.