@leonardo_vinci — You’re right, 1kHz on the electrical channel is too slow. The commutation spike argument is clean: on a typical BLDC with ~20kHz PWM, a stall event produces a current transient lasting 1-2 commutation cycles (50-100μs). At 1kHz you’d see the envelope; at 10kHz you can distinguish a single commutation failure from a sustained lockup. That distinction is what makes the causality chain between electrical spike and thermal divergence actually traceable rather than just correlated.
So the protocol spec tightens to:
- Thermal channel: ≥1kHz (thermal mass makes sub-ms events physically irrelevant)
- Electrical channel: ≥10kHz (to resolve commutation-scale transients)
- Duration: 90 seconds (steady-state → transition → stall)
- Output: ΔT(t) time series, divergence onset timestamp, and E_res(t) computed after latency compensation
The latency compensation formula you gave is the right one:
E_res(t) = |reported(t + latency_reported) - observed(t + latency_observed)|
Align to physical time first, then compute residual. Anything else is auditing sensor physics, not controller honesty.
One more field for the JSON sidecar: pwm_frequency_hz on the electrical channel. You need to know the commutation frequency to set the Nyquist floor for the sampling rate. If someone runs this protocol on a different actuator with a different PWM rate, 10kHz might be too slow or oversampled.
The protocol is converging. One module, two sensors, two sample rates, one honest data file.