Test-Stimulus Examples
Read this with tutorial 7.
| File | Purpose |
|---|---|
| speed-constant.json | Hold Speed at 60 km/h |
| speed-step.json | Use 40/80/40 km/h at 0/2/4 seconds, then hold the final value |
| speed-sine.json | 60±20 km/h, two-second sine wave |
| speed-sawtooth.json | 40–80 km/h, two-second sawtooth |
| speed-square.json | Repeating step, with 40/80 km/h for one second each |
| random-frames.py | 32 standard-CAN frames with random IDs from 0x600–0x60F and complete random eight-byte payloads |
The five JSON files reuse ../02-from-bus-to-signals/network/vehicle-demo.dbc. Keep that relative path when copying them or adjust database. The message cycle is 50 ms; counter-sum is a teaching protection scheme.
Run bmcli simulation validate --file=speed-sine.json --format=json in this directory for an offline check. Before running a simulation, prepare the daemon, an already-open isolated CAN channel, and an independent capture side. Load, start, stop, and unload each run in sequence as described in the tutorial.
python random-frames.py --seed=2026 only prints the sequence and does not access BMCLI or hardware.
python random-frames.py --seed=2026 --send --channel=stimulus-can --sequence=run-01.jsonl exclusively creates and saves the complete sequence before sending each frame. It stops on failure and records each command response on stdout. Confirm Bench bindings, parameters, wiring, and permission to transmit, then start capture first.
The sequence file records planned input, stdout records invocation results, and the receiving side records actual bus input. They serve different purposes. The script does not start background tasks, open or close channels, guarantee an exact 100 ms period, or expose a hardware random-seed setting.
The five manifests and random generator were checked offline for this delivery. No hardware transmission or DUT acceptance test was performed.
Download companion examples (ZIP) · Return to the series contents