A DBC file is a text description of a CAN network: which IDs exist, which signals sit in which bits, and how to turn those bits into physical units. Tools such as cantools, SavvyCAN, and many loggers read it so they can plot "battery current" instead of raw hex.
Treat a DBC as a hypothesis you can test. Wrong scale, wrong plot. Publish it with how you validated it (bench, drive, charger) and which vehicle it applies to.
The two lines you will see first
Messages use BO_. Signals use SG_:
BO_ 298 BMS_Status: 8 Vector__XXX
SG_ PackCurrent : 0|16@1- (0.1,0) [-3276.8|3276.7] "A" Vector__XXXCAN ID 298 (decimal), 8-byte payload. PackCurrent starts at bit 0, is 16 bits, little-endian (@1), signed (-). Multiply by 0.1 to get amperes. Brackets are the intended range; units are in quotes.
Endianness and signedness
Mixing up @1 and @0 (Intel vs Motorola bit numbering) is the usual way a decode looks like noise. Same for signed vs unsigned. If current explodes at standstill, check the sign bit before inventing a new scale.
What a good open DBC includes
- Make, model, year range, and pack or region variant if it matters
- Bus name and bitrate
- Signal names a stranger can read (comment internal abbreviations)
- Enum comments (0 = open, 1 = closed)
- Unknown bytes left unknown. Do not invent names to look complete
DBC is not the only format, but it is the one most EV tools already speak. Prefer a DBC plus a short note over a screenshot of a closed app.
Related: CAN on EVs ยท how to send a file.