What does an SG_ line say?
A DBC file describes the messages on a CAN bus. Each message starts with a BO_ line, and each signal inside it has an SG_ line. The SG_ line holds everything the tool needs to turn bits into a value.
SG_ EngineSpeed : 24|16@1+ (0.125,0) [0|8031.875] "rpm" Vector__XXX
| Part | In the example | Meaning |
|---|---|---|
| Name | EngineSpeed | Signal name. Letters, digits and underscore. |
| Start bit | 24 | Intel: the least significant bit. Motorola: the most significant bit. |
| Length | 16 | Number of bits. |
| Byte order | @1 | 1 is Intel (little-endian), 0 is Motorola (big-endian). |
| Sign | + | + unsigned, - signed two's complement. |
| Factor, offset | (0.125,0) | Value = offset + factor x raw. |
| Minimum, maximum | [0|8031.875] | Valid physical range. |
| Unit, receiver | "rpm" Vector__XXX | Unit text and the node that reads the signal. |
Intel or Motorola?
Byte order decides which byte holds the high part of a multi-byte value. Intel puts the low byte first. Motorola puts the high byte first. Read the same bytes with the wrong order and the value can be off by thousands.
Intel 0|16@1
Motorola 7|16@0
Worked example: engine speed
A CAN-logger maker's guide publishes this example for the J1939 message EEC1. It is the sample loaded in the tool.
- Payload
FF FF FF 68 13 FF FF FF. The signal is24|16@1+: Intel, 16 bits from bit 24. - Bit 24 is bit 0 of byte 3, so the signal uses bytes 3 and 4:
68and13. - Intel puts the low byte first, so the raw value is
0x1368= 4968. - Value = 0 + 0.125 x 4968 = 621 rpm.
Why does my editor show another start bit?
For Motorola signals there are two habits. The DBC file stores the most significant bit as the start bit. Some editors display the least significant bit, because it is easier to place on a grid. Both describe the same signal. The tool accepts either and always writes the DBC form.
| Signal | Start as MSB, DBC | Start as LSB, some editors |
|---|---|---|
| 12 bits from byte 0 | 7 | 12 |
| 16 bits from byte 0 | 7 | 8 |
| 4 bits, top of byte 0 | 7 | 4 |
Signed values and scaling
A signed signal uses two's complement over its own length, not over a whole byte. A 12-bit signal whose top bit is 1 is negative even if the byte around it looks positive. After the sign, the factor and the offset turn the raw number into the physical value.
What usually goes wrong?
- The value is far too large. The byte order is wrong. Try the other order and compare with the dashboard.
- A Motorola signal is shifted. The start bit was copied from an editor that shows the LSB. Switch the start bit setting.
- Negative values look huge. The signal is signed but was read as unsigned.
- Every bit is 1. In J1939 and many other protocols that means the value is not available.
- The signal runs past the payload. The frame is shorter than the definition expects, or the start bit is wrong.
Sources and limits
- SG_ syntax, byte order and the EngineSpeed example: DBC file explained (CAN-logger maker guide). The EEC1 payload: J1939 introduction (same guide).
- Signal definitions for your vehicle are yours to enter. The tool ships none apart from the published example.
- The EEC1 engine speed layout (bytes 4 and 5 counted from 1, 0.125 rpm per bit) could not be checked in the official SAE J1939 text, which is sold. Last checked 2026-11-03. Use it for practice and take real definitions from the vehicle maker.
- Multiplexed signals are decoded against the same payload without checking the multiplexer value. Floating-point signals are not covered.
- Everything runs in your browser. If you ask for the report or the CSV by e-mail, your inputs, and the DBC text when it is short, are sent to our server with the request and kept for up to 45 days. A share link carries the text only when it is short.
- This page does not say that any device reads a given CAN signal. That depends on the model and its configuration.