Randomly returns 3,000,000 sometimes. We’re using it to determine how accurate our bang-bang is by averaging the difference between the setpoint RPM and the real RPM, and it works well until at seemingly random times it will return strange high numbers. Other than the high numbers, it returns accurate ones. We are using a once-per-rev hall effect sensor and we’ve gotten (by graphing the data) within 20± rpm of what we’d like. The random large numbers mess up our data, and we’re wondering what would cause this to happen.
This is getPeriod():
public double getPeriod() {
double period;
if (m_counter.readTimerOutput_Stalled()) {
return Double.POSITIVE_INFINITY;
} else {
period = (double) m_counter.readTimerOutput_Period() / (double) m_counter.readTimerOutput_Count();
}
return period / 1.0e6;
}
How would m_counter.readTimerOutput_Stalled() return true? That’s when it is considered “stopped”, correct?
We purchased the one pictured here from their team. (it is a newer “version”, but as far as I can tell the same hardware components.) I seem to remember it having this sensor, but I could be wrong. This is what it looks like when mounted.
I can’t tell for sure from the angle the picture is taken at, but it doesn’t look like the Hall sensor is mounted in the correct orientation relative to the magnet. Could you post a couple of pics taken from x,y,&z directions?
Also, it looks like the Hall end of the PCB is unsupported and the Hall chip is dangling at the end of its long leads. It could be vibrating. Try stuffing some tissue paper under the leads to dampen it and see if it makes a difference. Easy enough to try.
You definitely don’t have the Hall sensor oriented correctly. The “flat” part of the sensor should be perpendicular to the magnet. If you don’t bend anything, then the correct orientation is with your mounting board parallel to the face your magnets are mounted on. Preferably with all those components on the side facing the wheel.
Or, you can bend the Hall sensor backwards, towards the back of the mounting board, away from the side all the components are mounted from.
(30 seconds later) EDIT: Also, why not put something in your GetRate function that tosses out obviously incorrect values like a period less than 0.0001 seconds or something?
It’s better to understand what’s causing the problem, fix it if you can, and make it work right than to cover up the problem.
But if you do filter out the glitches in software, then increment an error counter each time it happens. Monitor that error counter during non-competition use to make sure it isn’t getting worse and worse over time.
Thanks guys. We mounted it horizontally and added tissue to relieve vibration. The bug hasn’t come up since. We’re actually within 2-5rpm from our setpoint, which is awesome.
We had the same problem as the OP last year, with a similar data resolution, and this year (our values were more like 90,000 RPM). This is what we’ve done, for lack of a better solution.
EDIT: We’re using LabVIEW, and the Counter class’s Period output (from the Get.vi).
