07fbcc5dc2
4f82d01e gitignore
5cb83454 Honda FCM: diagnostic signals
d309cdce Added linter to opendbc (#203)
d452706f add requirements.txt
ec3b4595 deterministic dependency order
a265d351 Azure pipelines ci (#202)
bce9a2e1 packer depends on libdbc
5d5fdd6a no more python version of libdbc, everything through cython
541705bf move CANDefine to parser code
da25c52a add test for can define
0ba7926b unify can packer and parser
25d88009 consistent naming
a5c640a5 fix linter
be210fef remove obsolete make file
ffd9dca7 opendbc needs cereal
b559f63d remove more make
d0929496 seems to work now
41e80836 don't make
3254d1fc think scons works
eb78f6aa scons sort of working
0ef1e35d fix gitignore
e155e017 Can migration (#199)
3eded83a Honda: correct steering torque sensor sign to be consistent with standard convention (left+)
32f70e2f Fix outback endianness consistency (#196)
a7da471f Update subaru_outback_2015_eyesight.dbc (#195)
git-subtree-dir: opendbc
git-subtree-split: 4f82d01ebc78109888954d9807d320e3c27896fd
old-commit-hash: 683b6151ce
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 and Here a couple of good overviews.
How to start reverse engineering cars
opendbc is integrated with cabana.
Use panda to connect your car to a computer.
DBC file preprocessor
DBC files for different models of the same brand have a lot of overlap. Therefore, we wrote a preprocessor to create DBC files from a brand DBC file and a model specific DBC file. The source DBC files can be found in the generator folder. After changing one of the files run the generator.py script to regenerate the output files. These output files will be placed in the root of the opendbc repository and are suffixed by _generated.
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_ACCELin 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" PCMis better than:
SG_ VEHICLE_SPEED : 7|15@0+ (0.00620,0) [0|115] "mph" PCMHowever, the cleanest option is really:
SG_ VEHICLE_SPEED : 7|15@0+ (0.01,0) [0|250] "kph" PCM -
Signal 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_POSas:SG_ GAS_POS : 7|8@0+ (1,0) [0|100] "%" PCMHowever, 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] "%" PCMwhich 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.