An application can report what it scheduled and what the adapter API accepted. Only independent observation can show what appeared on the wire, and receiver-side evidence is still needed to show what the downstream system processed.
Four rates can exist at the same time
| Rate | Meaning | Typical evidence |
|---|---|---|
| Requested | The target configured for a signal or frame. | Scenario settings. |
| Scheduled | How often the application attempted to hand off the frame. | Application counters and timing diagnostics. |
| Accepted | How often the driver or adapter API accepted the request. | Transmit result and adapter benchmark. |
| Observed | What appeared on the bus or reached the receiver. | External CAN analyzer, logger, and receiver evidence. |
Estimate bus load before chasing software
Every CAN frame consumes arbitration, control, data, CRC, acknowledgement, inter-frame spacing, and possible bit stuffing. Higher payloads and higher frame rates consume more capacity. Multiple messages share the same bus, and retransmissions add work.
A simple estimate is useful for feasibility, but it is not a substitute for measurement. Leave margin for other traffic, clock tolerance, bursts, and error recovery.
Why inexpensive adapters can appear rate-offset
Windows scheduling, USB batching, driver buffering, serial-style adapter firmware, and timestamp behavior can create a repeatable difference between a configured rate and an observed rate. If the offset is stable, a trim can help reach a practical bench target.
That trim is calibration for a particular path. It does not create bus capacity, guarantee every frame reaches the receiver, or transfer automatically to another PC, driver, adapter, channel, or bus load.
A defensible timing test
- Record the PC, driver, adapter, firmware, channel, bitrate, CAN/CAN FD mode, and termination.
- Run a controlled single-message benchmark and note requested, scheduled, and accepted counts.
- Observe the same traffic with an independent analyzer over a long enough window.
- Add the intended scenario and background load.
- Confirm the receiver processes the frames and state transitions correctly.
- Save the evidence and the exact scenario with the test record.
What simCAN is designed to report
simCAN exposes schedule health and adapter-path diagnostics so you can see whether the Windows application or interface is falling behind. The built-in check helps characterize a repeatable path. It intentionally does not claim that an internal counter is independent wire proof.
Trial the complete path.
Use the exact Windows machine, driver, adapter, channel, bitrate, bus load, and receiver planned for the bench. Start in Dry run, then move to an isolated live setup with independent observation when timing matters.