I was going to give this a spin soon. I seem to recall that this was now in the main branch, so no need to use the dev branch?
So I include smoothingsensor.h as mentioned above, instantiate the hall sensors in the usual way (maybe give them a test or do the motor init first) and then instantiate the smoothingsensor, feeding it the hall sensor object. Then feed the motor object the smoothingsensor object so it uses that instead of using the hall object directly. Do I need to tell smoothingsensor the time constant for the filter or something?
Hm. Seems like I might encounter difficulty with the motor initialization routine, where it detects the pinouts and orientation of the hall sensors if it was trying to use the smoothingsensor object for that. I can probably skip that part though. I think my motor probably has well aligned hall sensors and I just gotta make sure I don’t get the wiring wrong.
That is correct. SmoothingSensor doesn’t have any filter constants, but you do need to set phase_correction = -_PI_6 for hall sensors. And it doesn’t have any state variables that need continuous updating, so you can call motor.linkSensor at any time to switch between using the HallSensor directly and going through the SmoothingSensor.
I don’t think it will interfere with calibration since the motor velocity should be zero at the time. But the calibration procedure doesn’t really work for hall sensors anyway unless you’re using trapezoid120 modulation. You have to manually tune the zero_electric_angle until top speed is the same in both directions.
I did that with hoverboard motors under no_load condition and it worked fine, but will that work with a fan?
Maybe @Anthony_Douglas has to cover the blades to avoid airflow…
For a fan it would depend on the type - many operate in one direction only and have their design optimized for pushing air one way. Others are bidirectional and designed symmetrically…
As an alternative to tuning the zero by going both directions you can also tune it going only one direction and watching for minimum current, I guess.
I can take the fan blades off, but what I did previously with the magnetic angle sensor was get it to go in one direction, then the other, and assume the reality was half way in between. I.e. the lag of the angle sensor’s reading of the rotor position is X degrees behind the electrical angle during slow, high current open loop motion (sine wave commutation) and Y degrees behind when rotating in the other direction. Assume the same small but not insignificant load in both directions. Thus, the real lag is equal in both directions. So we take the difference between X and Y and divide by two. That’s the bias of the sensor relative to the actual rotor position.
For the magnetic angle sensor I measured it all the way around with a pico but that ended up being really complicated. Hopefully my motor is a little better built than that, I doubt there is significant assymetry in the alignment of the halls. They seem to be pretty good quality motors.
This complication concerns me, though, I thought the halls were expected to just clocked in fairly accurately at the right positions. The motor seems to work pretty well and about the same in both directions with a “dumb” hall sensor based motor driver that I got on amazon.