Some sensors do not deliver the quantity you want to analyse — they deliver something the software still has to work out. A resolver delivers two amplitude-modulated voltages, not an angle. An incremental encoder delivers pulse trains, not a speed. A GPS receiver delivers text sentences. A Modbus register delivers integers. Decoding is the step that turns any of these into an ordinary channel with a unit, and the Decoder page is where you can do that step explicitly, look at the result, and save it.
| Decoder | Input | Output |
|---|---|---|
| Resolver | Sine and cosine channels, optionally the excitation carrier — all on analog inputs | Speed of rotation, angle, wrapped angle, frequency |
| Encoder | Incremental encoder A (and optionally B, Z) on pulse inputs. Works both for a real shaft encoder and for the A/B/Z a motor controller derives from a resolver | Speed of rotation, angle, wrapped angle, frequency |
| Trigger | A pulse-shaped waveform on an analog input (magnetic pickup sine wave, TTL fed into an analog input, amplified photoelectric output) | Speed of rotation, angle, wrapped angle, frequency |
| GPS | An NMEA log (raw serial capture or text file) | Speed over ground, latitude, longitude, altitude |
| Modbus | A process record written by the RS485 / Modbus side-recording (CSV) | One channel per point — speed, torque, temperature, bus voltage… |
| CAN | A message log (Vector ASC, PEAK TRC or a generic CSV), or the raw bus stream stored inside a
recording — plus the .dbc that defines the signals |
One channel per signal — vehicle speed, motor torque, coolant temperature… |
If the file was recorded with this software, the channel setup already records what each line was connected to (sensor type Resolver Sin, Encoder A, RPM Analog and so on), and the decoders find their inputs by themselves. For files recorded elsewhere there is no such metadata, so every decoder also accepts an explicit channel name or index — the sensor type is a convenience, never a requirement.
The angle information of a resolver sits in the amplitude ratio of the two windings. A digital pulse input squares its input to two levels, which throws that amplitude away and leaves only the carrier zero crossings. Encoder A/B/Z, being digital by nature, belong on pulse inputs.
Three settings that are easy to get wrong when recording a resolver:
With both A and B available you can switch QuadratureX4 on. Counting all four state transitions per period gives four times the angular resolution, and because the direction is decided at every single transition it also follows a change of direction during the measurement. Without B, the direction cannot be determined and steady rotation is assumed.
If the diagnostic line reports diagonal transitions, the pulse bit-stream rate was too low for the edge density — either reduce the line count or raise the sample rate, because in that state the count is no longer reliable.
With a Z channel the angle zero is pinned to the first index pulse, so it is reproducible across recordings — which is what makes a one-time d-axis offset calibration reusable. Without Z the zero is simply the start of the channel, so any calibration derived from it is valid for that one file only.
A register keeps its value between two polls, so the decoder repeats the last value up to the next sample (zero-order hold). Interpolating would invent a ramp that never existed and would round off exactly the load steps a pass/fail criterion looks at. There is deliberately no interpolation option: the same zero-order-hold code serves the live serial/TCP recording, the after-the-fact CSV merge and this decoder, so a value recorded live and the same value decoded offline agree bit for bit.
A bus signal only updates when its message arrives, so between two messages the decoder holds the last value — the same zero-order hold used everywhere else in this software. Note that some other tools store CAN channels interpolated between messages instead; when you compare numbers against such a tool, expect differences of up to one message-interval of change on fast-moving signals. That is the interpolation choice, not a decoding difference.
Binary Vector BLF logs are not read: it is a compressed proprietary container, and getting it wrong would mean silently producing wrong messages rather than failing. Export to ASC or CSV first.
A DBC belongs to the vehicle manufacturer and often does not travel with the data. If the recording
also holds the bus signals already decoded by the software that made it, those are ordinary
channels — usable straight away, no DBC needed. And if you only have the raw stream, the bit
definition can often be recovered from those decoded channels; ask support about the
--can-match-signal diagnostic. Be aware that a definition recovered this way is only
guaranteed equivalent over the range present in that recording: bits that never changed
cannot be told apart from bits that do not exist.
A DBC answers the same question a sensor sensitivity does — how do the raw counts on this line become a physical quantity — so it belongs in the sensor library. Right-click in the sensor library and choose Import DBC as CAN sensor…; each signal in the file opens a list of every signal the file defines — a full-vehicle DBC has several hundred. Nothing is ticked by default: you pick the handful you actually record, and only those enter the library. Type in the filter box to narrow the list, then Select All takes the current matches only — so "filter Spd, select all" is one gesture. Several DBCs can be imported at once, which is what a real vehicle needs (powertrain, chassis, body…).
Sensor libraries exported from other software are read including their CAN sensors. Note that such files number signal bits differently from a DBC; the import converts between the two conventions, so what you see in the library always matches the DBC convention.