commaai / opendbc Goto Github PK

Hi commaai,

I tried to read signals from my 2017 corolla from OBD CAN bus (pin6 (CANH) and pin14 (CANL)) with a CAN tool (Kvaser usbcan interface). I used this dbc file to parse the data, but failed. It can't parse the data. Is this dbc for the CAN bus I chose or is there any other secret CAN bus in OBD connector.
Thanks. @rbiasini, @pd0wm.

Very interesting project.
However, how can I create a dbc like these available in this repo? Is Panda that generates the dbc according to the frames sniffed or another tool?

Thanks

hello
i am student on automotive and want to do some project about mqb virtual cluster can signals

vw_mqb_2010.dbc file help me so much because i discovered how to power on the cluster but i need help from somebody who can convert this file to suppored canDB++ or busmaster

many thanks and i will return with more info about this incredible virtual cockpit cluster

Hi Guys, I am using cantool for python, when I was trying to upload the dbc to my GUI the bitstruct.error arised with the following error description:

bitstruct.Error: "s15" requires -16384 <= integer <= 16383

So, I noticed the bit length defined in the dbc for these two signals is 15. I changed it to 16 bits, and everything starts to work properly. In general these are the suggested changes:

BO_ 552 ACCELEROMETER: 8 XXX
 SG_ ACCEL_Z : 23|16@0- (1,0) [0|32767] ""  XXX
 SG_ ACCEL_X : 7|16@0- (0.001,0) [-20|20] "m/s2"  XXX

Since this directly relates to DBC files, this seems like the right place to log this bug.

When saving to github from cabana: CM_ "CHFFR_METRIC" gets taken out of the file

I have noticed that there is an extremely large number of dbc files that have overlapping signals. This makes it impossible to use the dbc file to properly encode and decode a can message.

I spent a long number of hours fixing the gm_global_a_* dbc files so there are no more overlaps. I am not sure to what extent the others have overlaps I would have to check each file that is not generated. I know I have loaded a few files other then the gm_global_a_* files and there are signal overlaps in the ones I loaded.

We have a single can valid flag per CAN parser for the frequency checks. Instead, each message should maintain its own valid flags for checksum, counter, and frequency validity.

Add a strict average frequency check in addition to the instantaneous check

Currently, it seems that only the top level input to the generator can have imports. It would be useful if imported files could themselves contain imports.

I could have used this when refactoring the honda files to share common definitions among models based on the Fit platform.

wanted

chain of imports: honda_hrv_touring_2019_can -> _honda_fit_2018 -> _honda_2017 / _comma

current situation

the top-level file must import transitive dependencies explicitly, in the correct order:

CM_ "IMPORT _honda_fit_2018.dbc";
CM_ "IMPORT _honda_2017.dbc";
CM_ "IMPORT _comma.dbc";

Now that we wait until the CANParser state is valid in controlsd, there's no need to set safe default values.

Hi,

I just wanted to report what I think are some errors/inconsistencies/invalid things on few DBC here.

While writing my own DBC parser, I end up with something working on almost everything here (I was using this repo as my testing oracle to see if everything was working fine on my end), however there is still few things I'm not able to parse, but I'm confident that my parser is correct.

I'll try to list in a diff format what I've done in order to make all files pass.

diff --git a/ford_lincoln_base_pt.dbc b/ford_lincoln_base_pt.dbc
-VAL_ 934 SodSnsLeft_D_Stat 3 "Second_Warning_Audio" 2 "System_Failure" 1 
+VAL_ 934 SodSnsLeft_D_Stat 3 "Second_Warning_Audio" 2 "System_Failure" 1 "" ;

Misses a value description for value 1, also misses ;.

diff --git a/ford_lincoln_base_pt.dbc b/ford_lincoln_base_pt.dbc
-CM_ VAL_ 970 Lkas_Alert 15 "no_alert" 3 "high_intensity" 2 "mid_intensity" 1 "low_intensity" ;
+VAL_ 970 Lkas_Alert 15 "no_alert" 3 "high_intensity" 2 "mid_intensity" 1 "low_intensity" ;

Dunno why there is a CM_ here, it makes no sense to be honest. Since it is in the middle of all VAL_ declarations, I ended up deleting the suspicious CM_ keyword. Moreover, value table are not eligible for comment.

diff --git a/ford_lincoln_base_pt.dbc b/ford_lincoln_base_pt.dbc
-VAL_ 972 LaActAvail_D_Actl 3 "LKA_LCA_LDW_Avail" 2 "LCA_LKA_Avail_LDW_Suppress" 1 "LCA_LKA_Suppress_LDW_Avail" 0
+VAL_ 972 LaActAvail_D_Actl 3 "LKA_LCA_LDW_Avail" 2 "LCA_LKA_Avail_LDW_Suppress" 1 "LCA_LKA_Suppress_LDW_Avail" 0 "" ;

Misses a value description for value 0, also misses ;.

diff --git a/ford_lincoln_base_pt.dbc b/ford_lincoln_base_pt.dbc
-VAL_ 984 AhbHiBeam_D_Rq 3 "NotUsed" 2 "HighBeamRecommended" 1 "LowBeamRecommended" 0 "DeactivatedUnavailable" ; "LCA_LKA_LDW_Suppress" ;
+VAL_ 984 AhbHiBeam_D_Rq 3 "NotUsed" 2 "HighBeamRecommended" 1 "LowBeamRecommended" 0 "DeactivatedUnavailable" ;

There is a value description after the end of the statement. Anyway if it is needed, it also misses a value for it.

diff --git a/honda_civic_touring_2016_can_generated.dbc b/honda_civic_touring_2016_can_generated.dbc
-VAL_ 884 DASHBOARD_ALERT 0 "none" 51 "acc_problem" 55 "cmbs_problem" 75 "key_not_detected" 79 "fasten_seatbelt" 111 "lkas_problem" 131 "brake_system_problem" 132 "brake_hold_problem" 139 "tbd" 161 "door_open"
+VAL_ 884 DASHBOARD_ALERT 0 "none" 51 "acc_problem" 55 "cmbs_problem" 75 "key_not_detected" 79 "fasten_seatbelt" 111 "lkas_problem" 131 "brake_system_problem" 132 "brake_hold_problem" 139 "tbd" 161 "door_open" ;

Misses ;.

diff --git a/honda_clarity_hybrid_2018_can_generated.dbc b/honda_clarity_hybrid_2018_can_generated.dbc
-VAL_ 884 DASHBOARD_ALERT 0 "none" 51 "acc_problem" 55 "cmbs_problem" 75 "key_not_detected" 79 "fasten_seatbelt" 111 "lkas_problem" 131 "brake_system_problem" 132 "brake_hold_problem" 139 "tbd" 161 "door_open"
+VAL_ 884 DASHBOARD_ALERT 0 "none" 51 "acc_problem" 55 "cmbs_problem" 75 "key_not_detected" 79 "fasten_seatbelt" 111 "lkas_problem" 131 "brake_system_problem" 132 "brake_hold_problem" 139 "tbd" 161 "door_open" ;

Misses ;.

diff --git a/mazda_2017.dbc b/mazda_2017.dbc
-BO_ 1275 2017_5: 8 XXX
- SG_ counter : 4|5@0+ (1,0) [0|255] "" XXX
-
-BO_ 1070 2017_1: 8 XXX
-
-BO_ 1183 2017_2: 8 XXX
-
-BO_ 1243 2017_3: 8 XXX
- SG_ NEW_SIGNAL_1 : 7|64@0+ (1,0) [0|18446744073709552000] "" XXX
 
-BO_ 1178 2017_6: 8 XXX
- SG_ NEW_SIGNAL_1 : 7|64@0+ (1,0) [0|18446744073709552000] "" XXX
-
-BO_ 1179 2017_7: 8 XXX
- SG_ NEW_SIGNAL_1 : 7|64@0+ (1,0) [0|18446744073709552000] "" XXX
-
-BO_ 1435 2017_8: 8 XXX
-

Those can't be valid signal name (2017_X).
It has to starts with either alpha_char or _.

diff --git a/toyota_sienna_xle_2018_pt_generated.dbc b/toyota_sienna_xle_2018_pt_generated.dbc
-VAL_ 610 LKA_STATE 25 "temporary_fault" 9 "temporary_fault2" 5 "active" 1 "standby"
+VAL_ 610 LKA_STATE 25 "temporary_fault" 9 "temporary_fault2" 5 "active" 1 "standby";

Misses ;.

diff --git a/vw_mqb_2010.dbc b/vw_mqb_2010.dbc
-BU_: Airbag_MQB BAP_Tester_MQB BMS_MQB Datenlogger_MQB Gateway_MQB Getriebe_DQ_Hybrid_MQB Getriebe_DQ_MQB LEH_MQB Motor_Diesel_MQB Motor_Hybrid_MQB Motor_Otto_MQB SAK_MQB Waehlhebel_MQB Vector__XXX 9 l c i XXX
+BU_: Airbag_MQB BAP_Tester_MQB BMS_MQB Datenlogger_MQB Gateway_MQB Getriebe_DQ_Hybrid_MQB Getriebe_DQ_MQB LEH_MQB Motor_Diesel_MQB Motor_Hybrid_MQB Motor_Otto_MQB SAK_MQB Waehlhebel_MQB Vector__XXX l c i XXX

According to specification, 9 can't be valid network node name.
It has to starts with either alpha_char or _.

diff --git a/vw_mqb_2010.dbc b/vw_mqb_2010.dbc
-CM_ SG_ 159 EPS_HCA_Status "Status of Heading Control Assist feature"
+CM_ SG_ 159 EPS_HCA_Status "Status of Heading Control Assist feature";

Misses ;.

diff --git a/vw_mqb_2010.dbc b/vw_mqb_2010.dbc
-CM_ SG_ 159 EPS_VZ_BLW "Raw steering angle, direction"
+CM_ SG_ 159 EPS_VZ_BLW "Raw steering angle, direction";

Misses ;.

diff --git a/vw_mqb_2010.dbc b/vw_mqb_2010.dbc
-CM_ SG_ 294 3 "May be zero when sent by older cameras";
-CM_ SG_ 294 7 "May be zero when sent by older cameras";
-CM_ SG_ 294 254 "May be zero when sent by older cameras";

According to specification, those can't be valid signal name (3, 7, 254).
It has to starts with either alpha_char or _.

I'd like the generator to be able to merge multiple partial message definitions into a coherent output. (Currently, I believe a redefined message will silently overwrite the entire previous definition.) It should raise an error if the merge inputs have duplicate or overlapping fields.

I wanted to use this when refactoring honda files to share common definitions for Fit platform models as much as possible.

wanted

in _honda_fit_2019.dbc:

BO_ 422 SCM_BUTTONS: 8 SCM
 SG_ CRUISE_BUTTONS : 7|3@0+ (1,0) [0|7] "" EON
 SG_ LIGHTS_SETTING : 1|2@0+ (1,0) [0|3] "" EON
 SG_ MAIN_ON : 47|1@0+ (1,0) [0|1] "" EON
 SG_ CRUISE_SETTING : 43|2@0+ (1,0) [0|3] "" EON
 SG_ COUNTER : 61|2@0+ (1,0) [0|3] "" EON
 SG_ CHECKSUM : 59|4@0+ (1,0) [0|3] "" EON

in honda_hrv_touring_2019_can.dbc

CM_ "IMPORT _honda_fit_2018.dbc";

BO_ 422 SCM_BUTTONS: 8 SCM
 SG_ DRIVERS_DOOR_OPEN : 63|1@0+ (1,0) [0|1] "" EON

current situation

I cannot put the SCM_BUTTONS message definition in the common file. Since some models have an added field, the entire message must be defined in each top-level dbc.

I want to convert can log file(.csv) to can signal.

link
In this link, can log file can be converted to can message.

How can I do it??

Thanks ahead.

I'm trying to get the semantics of the naming. There doesn't seem to be a common guideline for naming messages and signals.

What do the prefixes stand for, is there an overview somewehere?

Any details on how to access the Civic 2016+ Touring? I've connected CAN to the BCM module but get no output. Is it 33.333kbps or 125kbps? A 60 or 120 ohm resistor is needed? HSCAN at the OBD port works fine at 500kbps, but nothing shows on BCAN wires, I'm attached to the BCANH and BCANL of the iDataStart T-harness which is connected between the remote start and the BCM

Found while writing #568. Let's enable the check and fix all the violations.

It is i16 signal so max cannot be 65535 here:

SG_ CR_Mdps_StrAng : 24|16@1- (1,0) [0|65535] "" XXX

https://github.com/commaai/opendbc/blob/master/hyundai_kia_generic.dbc#L1551

When trying to load any of the generated files using CANdb++ v3.1.9 an error message of , syntax error pops up 2 times and then a message stating

The database file
`some database.dbc` cannot be opened!

There are several problems with the generated files.

problem 1:
The generated files have the imported data placed before the VERSION and the NS_
here is an example of what I am talking about. This is from the top of the acura_ilx_2016_can_generated.dbc file

CM_ "AUTOGENERATED FILE, DO NOT EDIT"


CM_ "Imported file _comma.dbc starts here"
BO_ 512 GAS_COMMAND: 6 EON
 SG_ GAS_COMMAND : 7|16@0+ (0.253984064,-83.3) [0|1] "" INTERCEPTOR
 SG_ GAS_COMMAND2 : 23|16@0+ (0.126992032,-83.3) [0|1] "" INTERCEPTOR
 SG_ ENABLE : 39|1@0+ (1,0) [0|1] "" INTERCEPTOR
 SG_ COUNTER_PEDAL : 35|4@0+ (1,0) [0|15] "" INTERCEPTOR
 SG_ CHECKSUM_PEDAL : 47|8@0+ (1,0) [0|255] "" INTERCEPTOR

BO_ 513 GAS_SENSOR: 6 INTERCEPTOR
 SG_ INTERCEPTOR_GAS : 7|16@0+ (0.253984064,-83.3) [0|1] "" EON
 SG_ INTERCEPTOR_GAS2 : 23|16@0+ (0.126992032,-83.3) [0|1] "" EON
 SG_ STATE : 39|4@0+ (1,0) [0|15] "" EON
 SG_ COUNTER_PEDAL : 35|4@0+ (1,0) [0|15] "" EON
 SG_ CHECKSUM_PEDAL : 47|8@0+ (1,0) [0|255] "" EON

VAL_ 513 STATE 5 "FAULT_TIMEOUT" 4 "FAULT_STARTUP" 3 "FAULT_SCE" 2 "FAULT_SEND" 1 "FAULT_BAD_CHECKSUM" 0 "NO_FAULT" ;


CM_ "Imported file _honda_2017.dbc starts here"
VERSION ""


NS_ :
	NS_DESC_
	CM_
	BA_DEF_
	BA_
	VAL_
	CAT_DEF_
	CAT_
	FILTER
	BA_DEF_DEF_
	EV_DATA_
	ENVVAR_DATA_
	SGTYPE_
	SGTYPE_VAL_
	BA_DEF_SGTYPE_
	BA_SGTYPE_
	SIG_TYPE_REF_
	VAL_TABLE_
	SIG_GROUP_
	SIG_VALTYPE_
	SIGTYPE_VALTYPE_
	BO_TX_BU_
	BA_DEF_REL_
	BA_REL_
	BA_DEF_DEF_REL_
	BU_SG_REL_
	BU_EV_REL_
	BU_BO_REL_
	SG_MUL_VAL_

BU_: EBCM ADAS PCM EPS VSA SCM BDY XXX EPB EON

problem 2:
The comment (CM_) statement syntax is incorrect. comments are only be able to be applied to signals (SG_), messages (BO_), environment variables (EV_) and nodes (BU_)

CM_ SG_ 1234 SIGNAL_NAME "comment here";
CM_ BO_ 1234 "comment here";
CM_ EV_ VARIABLE_NAME "comment here";
CM_ BU_ NODE_NAME "comment here";

where 1234 is the id of a message

problem 3:
any nodes that are used in the message definitions and the signal definitions need to be added to the node deceleration statement (BU_)

problem 4:
Indenting problem with the imported data.
Here is an example

CM_ "Imported file _comma.dbc starts here"
BO_ 359 STEERING_IPAS_COMMA: 8 IPAS
 SG_ STATE : 7|4@0+ (1,0) [0|15] "" XXX
 SG_ ANGLE : 3|12@0- (1.5,0) [-510|510] "deg" XXX
 SG_ SET_ME_X10 : 23|8@0+ (1,0) [0|255] "" XXX
 SG_ SET_ME_X00 : 31|8@0+ (1,0) [0|255] "" XXX
 SG_ DIRECTION_CMD : 38|2@0+ (1,0) [0|3] "" XXX
 SG_ SET_ME_X40 : 47|8@0+ (1,0) [0|255] "" XXX
 SG_ SET_ME_X00 : 55|8@0+ (1,0) [0|255] "" XXX
 SG_ CHECKSUM : 63|8@0+ (1,0) [0|255] "" XXX

CM BO_ STEERING_IPAS_COMMA "Copy of msg 614 so we can do angle control while the Park Assist ECU is connected (Panda spoofs 614 with 359 on connector J70). Note that addresses 0x266 and 0x167 are checksum-invariant";

 BO_ 512 GAS_COMMAND: 6 EON
  SG_ GAS_COMMAND : 7|16@0+ (0.159375,-75.555) [0|1] "" INTERCEPTOR
  SG_ GAS_COMMAND2 : 23|16@0+ (0.159375,-151.111) [0|1] "" INTERCEPTOR
  SG_ ENABLE : 39|1@0+ (1,0) [0|1] "" INTERCEPTOR
  SG_ COUNTER_PEDAL : 35|4@0+ (1,0) [0|15] "" INTERCEPTOR
  SG_ CHECKSUM_PEDAL : 47|8@0+ (1,0) [0|255] "" INTERCEPTOR

 BO_ 513 GAS_SENSOR: 6 INTERCEPTOR
  SG_ INTERCEPTOR_GAS : 7|16@0+ (0.159375,-75.555) [0|1] "" EON
  SG_ INTERCEPTOR_GAS2 : 23|16@0+ (0.159375,-151.111) [0|1] "" EON
  SG_ STATE : 39|4@0+ (1,0) [0|15] "" EON
  SG_ COUNTER_PEDAL : 35|4@0+ (1,0) [0|15] "" EON
  SG_ CHECKSUM_PEDAL : 47|8@0+ (1,0) [0|255] "" EON

 VAL_ 513 STATE 5 "FAULT_TIMEOUT" 4 "FAULT_STARTUP" 3 "FAULT_SCE" 2 "FAULT_SEND" 1 "FAULT_BAD_CHECKSUM" 0 "NO_FAULT" ;

problem 5:
In the example above the syntax of the CM_ statement is incorrect
CM BO_ STEERING_IPAS_COMMA "Copy of msg 614 so we can do angle control while the Park Assist ECU is connected (Panda spoofs 614 with 359 on connector J70). Note that addresses 0x266 and 0x167 are checksum-invariant";
should read
CM BO_ 359 "Copy of msg 614 so we can do angle control while the Park Assist ECU is connected (Panda spoofs 614 with 359 on connector J70). Note that addresses 0x266 and 0x167 are checksum-invariant";

I am sure there are things I have missed but that is a starting point.

The ILX and Ridgeline (and Pilot, Passport) can use the same DBC for the gear shifter, however occasionally both ILX and Ruidgeline flip N and P. Either figure out which definition is correct, or find new signal, as it doesn't happen all the time, and Pilot and Passport seem to be unnafected.

Acura ILX: https://i.imgur.com/VtfExGn.jpeg
Ridgeline: https://i.imgur.com/c5mkNu3.jpeg

Dear community,

in the .dbc file, I find no reference to battery status, I know that on the Spy Pro App and from an OBC2 interface these are available. Can they be logged vie CAN?

thank you!

This is correct and tested - Conversion from milliarc second to decimal degrees. Signal length is 31 bits not 32. I suspect the first bit on each signal is a validity indicator.

BO_ 810 TCICOnStarGPSPosition: 8 K73_TCIC
SG_ GPSLongitude : 38|31@0- (2.77778e-07,0) [0|0] "Degrees" NEO
SG_ GPSLatitude : 6|31@0- (2.77778e-07,0) [0|0] "Degrees" NEO

Tried a lot of different options of messages of all cruise related addresses, nothing works

socialledge.com cannot be opened. this is a good alternative overview of DBC format.

Hi,
I'm analyzing the hyundai_kia_generic DBC and I've a question on the meaning of this BO_
TMU_GW_PE_01

My guess is that the TMU is the telematic ECU, but GW? Is it referred to the gateway? And PE?

Thanks

• overlapping signals
• duplicate message definitions
• mixed endianness
• duplicate value definitions
• orphan values and comments
• signal out of message bounds

Useful for debugging, car ports, or in release openpilot, as there's several places where we need the entire message: https://github.com/commaai/openpilot/blob/master/selfdrive/car/hyundai/carstate.py#L110

Hi,

I had a look at the LKASMode signal in this message:

BO_ 338 ASCMLKASteeringCmd: 6 NEO
 SG_ LKASteeringCmdActive : 7|1@0+ (1,0) [0|0] ""  NEO
 SG_ LKASteeringCmd : 5|14@0- (1,0) [0|0] ""  NEO
 SG_ RollingCounter : 23|2@0+ (1,0) [0|0] ""  NEO
 SG_ SetMe1 : 21|1@0+ (1,0) [0|0] ""  NEO
 SG_ LKASVehicleSpeed : 20|13@0+ (0.22,0) [0|0] "kph" NEO
 SG_ LKASMode : 36|2@0+ (1,0) [0|0] ""  NEO
 SG_ LKASteeringCmdChecksum : 33|10@0+ (1,0) [0|0] ""  NEO

It seems value=2 represents SuperCruise on. Any idea what value=1 means?

Thanks for any insights!

I am still checking but
BO_ 951 ESP_CONTROL: 8 ESP
SG_ BRAKE_LIGHTS_ACC : 18|1@0+ (1,0) [0|1] "" XXX

is not reporting correctly the braking on RAV4, on RAV4H it is correct.

Think the signal might be on 955
BO_ 955 ESP_CONTROL: 8 ESP
SG_ BRAKE_LIGHTS_ACC : 18|1@0+ (1,0) [0|1] "" XXX

The signals should be 31 bit signed big endian integers to turn them into milliarcseconds. They are currently 32 bit big endian unsigned signals. This won't work for those of us with negative longitude which is how I found the problem.

I tested this on a 2019 Equinox. I'm not sure if this error persists across all other GLOBAL-A cars or if the Equinox is special.

Also, a conversion factor of 2.77778e-07 for lat/long would turn them into degrees which is far easier to use than milli-arcseconds.

• See if LAT_ACCEL under KINEMATICS on 145 is also available on 148 for cars using 145. The LAT_ACCEL signal is defined in the same location in the message
• Fix duplicate gear signals defined
• A lot of these messages are common in bosch vehicles, possible unify:
  • DOORS_STATUS
  • STANDSTILL
  • GEARBOX
  • GAS_PEDAL_2

This shouldn't pass: 2ff9a92

Ideally, we can use a single DBC for all Toyotas, like we do with many of the more recent car ports. This can be done incrementally by doing the following:

• merging DBCs
• using common, universal signals when possible
• abstracting out repeated definitions into common DBCs

Hello,

I tried to open the DBC files from the repo with CANdb++ Editor (the original tool used to create such files) and it fails.
The reason for this is that the files (or the generator) don't follow the spec.
Most of parsers found on Internet don't enforce order of statements in DBC files, but the original editor does.

The spec is not disclosed officially, so most of information is gathered through reverse engineering.

I know of 2 parsers that do enforce ordering of sections like the original editor does:

1. https://bitbucket.org/tobylorenz/vector_dbc (reads data into C++ structures)
2. https://github.com/msalau/dbc-parser (just prints scanned info to stdout)

The second one is mine, so I can help with it.

The original DBC parser expects the following ordering (all the sectional are optional if not stated otherwise):

1. VERSION
2. NS_ : ...
3. BS_: (mandatory)
4. BU_: (mandatory)
5. VAL_TABLE_
6. BO_ and SG_
7. CM_
8. BA_DEF_
9. BA_DEF_DEF_
10. BA_
11. VAL_

Sections may not mix.
There are few more sections not listed here, but their use is less widespread.

Hope that helps.

Regards,
Maksim

Should show an error and throw an exception

Hi, @rbiasini i find you've change honda_odyssey_extreme_edition_2018_china_can.dbc 7 days ago.
I use odyssey_china 2019 with pedal, (first go , can error check connection) but somehow OP go green, but didn't accelerate or steer, I've compared 512/513 with other dbc, looks very different. maybe that was the reason for OP to run incorrectly with comma pedal?

P.S. the pedal we build run successful in DFU, flash over can, and pass through mode.

Currently we build the DBCs into a shared library, but we can get rid of this step at build-time if we can parse them at runtime.

❌ 's all over the PRs. Checks not being done either.

Will it at all be possible to use the OBD CAN to lock and unlock a vehicle? I assume there is no such CAN signal exposed? Does anyone have any experience? Remote Lock/Unlock would be such a neat feature to add ;)

Ideally, we can use a single DBC for all Hondas, like we do with many of the more recent car ports. This can be done incrementally by doing the following:

• merging DBCs
• using common, universal signals when possible
• abstracting out repeated definitions into common DBCs

Only one DBC in the 8 that imports _honda_2017.dbc uses a different STEERING_SENSORS. See if we can move this message into the common DBC, and see if that one odd DBC can import another base DBC.

A few DBCs also make the steering rate negative with everything else the same, is this a mistake? Verify with data

Generally what I observed in my hyundai car is that all the CAN data I received is little endian based.

https://github.com/commaai/opendbc/blob/master/hyundai_kia_generic.dbc#L1063
defines following signal

SG_ CAN_VERS m0 : 0|6@1+ (1.0,0.0) [0.0|7.7] ""  _4WD,ABS,ESC,IBOX

.. which must be incorrect, max cannot be 7.7 with such fraction and offset

In this segment (6f63165f17c0e270|2022-03-19--23-09-55--92), a Genesis had a controls mismatch due to the car sending a message with an invalid checksum so panda stopped allowing messages but we don't check this in the CAN parser.

• Consider checksums and counters (need flags to ignore checksums in certain cases? eg. legacy HKG)
• Add checksum for Hyundai

could you please add a license file to the opendbc repo?

Hi, As part of a project, I've managed to reverse engineer binary files found in Xentry to obtain all this CAN data about all MB vehicles between 2000-2010. The 2 files attached are for the CAN B and C network for my MB model (W203)

I am too lazy to convert them to dbc...so just putting them here if anyone wants to convert them

203_b.txt
203_c.txt

Offsets and Length in these files are specified in bits from the start of the frame

The extractor lists 3 data types:

1. 'B' - Boolean
2. 'I' - Integer
3. 'E' - Enum - Each int value maps to a specific value such as P/R/N/D

You can find the extraction script here:
https://github.com/rnd-ash/MBUX-Port/blob/master/parse_dat_v3.py

The issue really seems to be the CAN parser architecture. Half of it is in C++ and the other half is in the cython wrapper. We should just move the whole thing into C++ and make the cython a thin wrapper.