I’m using a reed-switch and magnet to track the speed of a slow moving wheel. I’d like to get down to a few Hz, and ideally below 1 Hz. All is well when the RPMs of the wheel approaches 60 rpm (1Hz). I observe around 140 rpm on Mission-Planner with my main focus on an oscilloscope tracking the period of the wheel. As the period of the wheel approaches 1 sec, all hell breaks loose and then the RPMs
on Mission-Planner climb to 4000+. I plotted the RPM readings from 900 ms to 5 sec and the exponential decay of the wheel speed is as expected. No noise at all. The exponential decay of the wheel from say, 500 ms to 900 ms is equally as expected.
If someone familiar with libraries/AP_RPM/RPM_pin.cpp can take a look and suggest what fix needs to be applied I would be most appreciative.
Thank you for your response. Ah. Magic numbers … I changed the 1 Hz cutoff to 0.2 Hz and the RPMs started to make sense. Perhaps these cutoff frequencies, perfectly legitimate parameters to tweak, should be right in there with the other RPM parameters.
I’d also be very interested in RAW_RPM data, such as timestamps of “events” (contact closures). Similar analagous implementations from the sporting world publish event timestamps, delta_t (time since previous reading) and event (modulo N) number.
I’m new to the code base so I’ll have to study a bit more to see where this would be inserted appropriately. Your quick response to my initial question was much appreciated.
Adding magnets is certainly a solution as well, and the more the merrier, it defers the issue, but I guess that’s the point. Ultimately a proper wheel encoder that reports the exact position of the wheel is what I need. While not a common use case, its my use case.
Identification of the cutoff frequencies and ultimately making these parameters similar to “quality” and “scaling” should be considered. @iampete identified the location of these numbers, I modified the values as required and all is well.