Identify One CAN Message Stream Before Testing It
Write the selection contract first
“Check ID 0x200” is incomplete when two buses, both directions or multiple frame formats are present. Before measuring a period or declaring a response successful, write down the exact population being observed. This guide uses a controlled classical CAN example: CAN1, standard identifier 0x200, received data frames, one continuous recording. Its payload contract requires exactly two bytes; byte 0 is marker 0xAA and byte 1 is a counter that advances once per transmission from 0 through 15, then wraps to 0. This is an invented protocol for reasoning, not a vehicle signal definition or a CANoe test result.
| Selection field | Why it belongs in the contract | Counterexample if omitted |
|---|---|---|
| Capture point and CAN channel | Identify where the observation happened | The same ID on CAN2 is counted as a second CAN1 sender |
| Numeric ID and standard/extended format | The number alone does not describe the frame identity | Standard 0x200 and extended 0x200 are merged |
| Direction at that observation point | Separate the events relevant to the question | A transmission request and a received event are counted as two arrivals |
| Data/remote frame and classical CAN/FD format | Decide whether the payload interpretation applies | An incompatible frame enters a classical data-frame test |
| Recording segment | State which timestamps and counter history can be compared | A restart is interpreted as loss or reversed time |
CAPL provides isStdId and isExtId overloads for a message object or an identifier; the authorized reference returns 1 when the requested format matches. In source declarations, extended identifiers use an x suffix. Do not strip format information from an exported ID column and assume that the remaining numbers still identify unique streams.
For this guide, configure and verify a classical CAN test stream. On a bus carrying FD traffic, use the installed tool's documented frame-format filter and length access before adapting the examples. Do not infer classical format merely from a small payload or reuse the classical DLC-as-byte-count assumption as a general FD rule. The walkthrough deliberately does not invent a version-independent FD selector.
For actual payload length, the authorized reference documents long canGetDataLength(message msg), returning 0 through 64 valid payload bytes. Check availability in the installed version before using it. A length result answers how many payload bytes are valid; it does not replace the decision about which frame format belongs in the stream.
Keep selection and payload validation separate
First select the channel, format, ID, direction and frame kind. Preserve all selected data frames, including those with a wrong length or marker. Then classify each payload. Otherwise an invalid target frame disappears from the dataset and looks like a missing transmission.
For each original row, retain its timestamp, selection result and rejection reason. The on message example shows checking direction and RTR before reading bytes. Extend its payload condition to exactly two bytes only when using the contract above; a different ECU definition may allow a different length. A valid CAN frame can still be an invalid application message.
Use a counter to test a hypothesis, not declare a root cause
The following is synthetic input after stream selection and payload validation:
| Timestamp (ms) | Counter | Observation |
|---|---|---|
| 0 | 14 | Establish baseline |
| 100 | 15 | Expected next value |
| 200 | 0 | Expected wrap, not a reset by itself |
| 400 | 2 | One intermediate counter value was not observed |
| 400 | 2 | Same timestamp and counter need investigation |
Under this specific contract, compute d = (current − previous + 16) modulo 16. A value of 1 is the expected transition, 0 repeats the counter value, and 2 suggests an unobserved intermediate value. This interpretation requires ordered samples, no reset and fewer than 16 increments between observations. With a full counter cycle between samples, the same arithmetic is ambiguous. A counter that advances only when data changes would require a different rule.
The 200-to-400 ms gap and 0-to-2 transition agree with a possible missing observation. They do not prove that the sender transmitted counter 1, that a bus frame was lost, or where an observation was dropped. The last row could be a duplicated export row, a repeated application value or a second observed frame whose displayed time was rounded. Keep it until the original evidence distinguishes those explanations.
Locate the first point where evidence differs
Compare the sender's intended sequence, the original capture, the CAPL observer output and the exported file in that order. Match frame identity and counter, not only timestamp text. If the original capture contains counter 1 but the CSV does not, inspect export filtering before changing the sender. If the capture lacks it too, compare another correctly configured observation point and sender state; the CSV cannot resolve the physical cause.
| Trial | Expected classification | What to retain |
|---|---|---|
| One matching two-byte frame | Selected; payload accepted | Original row and both bytes |
| Same numeric ID on CAN2 or in extended format | Outside this stream | Selection reason |
| Matching data frame with one byte | Selected; payload rejected | Length mismatch, not “no frame” |
| Counter 15 followed by 0 | Normal wrap under this contract | Continuous segment and both rows |
| Restart before counter returns to 0 | Start a new comparison segment | Restart evidence and new baseline |
| Same frame exported twice | Investigate duplicate row identity | Original capture rows before deduplication |
After establishing the stream, export its timestamps to the interval analyzer using the timestamp walkthrough. The calculator does not see IDs, counters or payloads and cannot perform the classification above for you. For command success, add the application response and a bounded deadline from the test-module tutorial; arrival of any matching frame is only one piece of evidence.
Sources and validation boundary
The API details were checked against the authorized Vector references for on message, message declarations, DIR, RTR, isStdId/isExtId and canGetDataLength. The selection contract, synthetic rows and diagnostic matrix are original site analysis. No compilation, hardware trace or CANoe execution is claimed. Record your tool version, node placement, channel mapping and actual protocol definition when reproducing the procedure. See sources and validation limits.