Two logs use different sampling periods. Comparing pole magnitudes without their clocks can reverse your engineering conclusion.
Put the clock beside the pole
Imagine two firmware logs. One reports a decay multiplier of 0.905 every 0.2 s; another reports 0.779 every 0.5 s. The second number looks more aggressive. Convert both with σ=ln|z|/T and each gives approximately −0.5 per second. These logs describe the same decay rate, not a performance improvement. A report that drops T has dropped part of the model.
Use the lab to catch the mistake
Open Continuous & discrete poles and keep σ=−0.5 and ω=4. Pin T=0.2, record a prediction that the radius decreases, then change only T to 0.5. The prediction matches, but the continuous traces overlap. Inspect t=1 s in both. Fewer samples do not mean less physical settling time. Change σ instead if you want to alter the decay per second.
What to write in a design review
Record T, the method used to discretize, physical time units and whether the poles belong to an open or closed loop. This bench samples a mode exactly; it does not implement a sampled controller. Delays and hold behavior can move implemented closed-loop poles. After changing firmware timing, validate that actual loop rather than reusing a stability claim from this coordinate map.
Angles differing by 2π give the same z, so frequencies separated by 2π/T rad/s cannot be distinguished by these samples alone. Exact modal sampling preserves decay; implementing a feedback controller with a hold, computational delay or an approximate integrator is another problem. Do not infer that any slow sampled controller is safe from this picture. The bench has no actuator or feedback loop.