FWIW, the goal of smooth_time is to avoid oscillations due to a derivative response to noise. That is, if the actual temperature is 200 and a noisy reading returns 195, we want to avoid having the PID turn the heater full on to account for that massive (not real) change in temperature - turning the heater full on could lead to later high temperatures which then cause the inverse to occur and thus results in oscillations.
It does seem, however, that many boards have a relatively clean temperature signal and thus the downsides to smoothing (slower response) outweigh the advantages.
I donāt have any plans to remove the smoothing code. I think there may be a better default (in particular, a default of no smoothing).
At a high-level, that is what Marlin does. I donāt think thatās a good choice. It delays the PID response (each temperature is behind by up to 300ms). I also find it confusing - Iād like to know the temperature at a given time - it seems odd to me to report an average temperature over an extended time period. Sampling over extended periods may reduce some noise due to averaging out of low-frequency harmonics, but Iād be surprised it would be significant.
That does two things - it increases the PID update frequency and it reduces the time the host has to respond to a PID update. The latter would make ātimer too closeā errors more likely. Iām not sure the former has a significant gain. It shouldnāt be necessary to change heater rates 10 times a second - 3 times a second should be fine - heck once every 2-3 seconds should be fine.
For the sake of keeping all the information together, this is an example of some of the information I was going through when experimenting with the PID and derivative filtering:
Among other things, it provides good insight into how a moving average filter performs. Note that is also suggests that the rolling average filter is preferential to the more commonly used first order filter.