The duty cycle reading only has a memory of ~1 second.
How it works is it counts the number of rising edges (might be calling, but that wouldn’t matter, and it’s always the same one). Every second, it saves that number as the frequency, and then resets the counter. That is how frequency is computed. This happens continuously.
Additionally, every rising edge it resets a timer counter which runs at 40MHz. Then, on the falling edge, it multiplies how that counter by the current stored frequency, and that gives the perfect period high of the duty cycle, which is reported back to the user.
This is why there is only a memory of about 1 second. Every second, the frequency will refresh. However, if the sensor is actually plugged in the whole time, the frequency should be stable, and I have tested it to be very stable over long periods.
Note that this is only the DutyCycle portion that gets the absolute value. DutyCycle does not support resetting. DutyCycleEncoder adds another counter on top of this, which is used to count rollovers. However, resetting is handled at the high level by resetting the rollover counter, and grabbing the current duty cycle output as an offset. There might be some issues in this logic, as you’re not the first report of that. I will try to take a look into it this week and see if I find anything wrong.