How to determine the resolution of an embedded Hall Sensor D/C motor?

I ordered this motor from amazon recently since it seemed to have matched the needed specs to drive my smart-curtain project. When programming the encoder channels, I realized the encoder may not have the accuracy I thought it would have. The PPR spec for the motor is 11, which if I understand how these encoders work correctly, would only give me an resolution of 32.72 of a degree rotation (360/11).

I continued my search and found this one today, which claims to have "828" PPR. However, it gets this resolution by multiplying the actual PPR (12) by the gear ratio (69). I don't think this really gets me any closer, since I can not 'Poll' the sensor channels fast enough in order to tell the motor to stop somewhere within this resolution. I would only be able to tell the motor to go to the mechanical position by a factor of 30 degrees (360/12).

For my project, I would like to turn the motor with an accuracy of at least 1 degree, almost like a stepper motor. This way if the length of my curtains change after relocating to a different apartment, I could have a high degree of accuracy to still be flush to the bottom of any window frame.

I also considered a magnetic sensor from the bottom which could signal this instead, but this would introduce another piece of hardware to install, make cable management more difficult and I feel complicates things. I think it would be a much better design overall just have a single motor with a good encoder resolution to be able to determine this instead.

The speed of the motor would need to be between 86-100 rpm or so (give or take) to open 6 ft length of curtain between 6-8 seconds (given the diameter of the PVC being used).

Stepper motors almost sound like the thing to use here, but they were not considered because I need high torque, continuous rotation, and my speed requirements seem to be considerably high for these types of motors. Speed is apparently a specification that is left out of the product details for steppers, so it has been very challenging to find one that is fast enough for the project when browsing catalogs.

Given the information above:

Am I understanding how these encoders work correctly? The PPR on these encoders seem surprisingly low to me!

Should I be using for a stepper motor instead? If yes, where can I find one specific enough to meet my project requirements?

aspen1135:
I can not 'Poll' the sensor channels fast enough

Why do you think that?

aspen1135:
I would only be able to tell the motor to go to the mechanical position by a factor of 30 degrees (360/12).

Why do you think that?

aspen1135:
For my project, I would like to turn the motor with an accuracy of at least 1 degree, almost like a stepper motor. This way if the length of my curtains change after relocating to a different apartment, I could have a high degree of accuracy to still be flush to the bottom of any window frame.

Wow, high precision automatic curtains. Sounds like a cool project! I'm skeptical that you would actually need 1 degree of accuracy for this application, as I'd think there wouldn't be any harm in adding a little extra distance just to be sure they go all the way down even if it is off a few degrees. But maybe I just don't understand all the factors at play here.

pert:
Why do you think that?

I would not be able to get input from the two channels fast enough if the PPR is 11 or 12. I think we would need this to be greater than 360 to get it down to 1 degree of accuracy.

Full disclosure that this could just be a misunderstanding on how this works, so please feel free to correct me me if this is inaccurate. My lack of understanding is why I created the thread in the first place.

But why..? Because when looking at the second motor I linked, it says the 828 "PPR" is due to the result of (12 PPR * 69 Gear Ratio). If this really was 828 PPR, then we would get a degree accuracy of 828/360 or 0.43 degrees of a rotation. However, I don't think this is the case since the gear ratio is not factored in when receiving the channel input from the two Pulse Width channels. I think the signaled input is actually the originally stated '12' PPR instead.

I think the 828 number is misleading. Technically the gear ratio would mean there would be an interval in which the motor could rest to 0.43 degree of a resolution, but that doesn't mean we could signal the motor to stop within that time since the sensor's channels are only providing a pulse signal 12 times every revolution.

If we wanted to signal the motor to stop at the 45 degree position and we only have 12 pulses every 360 degrees, then we can only tell the motor to stop at the 30 degree or 60 degree position and not in between.

The terms "PPR" and "CPR" are kind of confusing to me when describing encoder resolution. I found a pretty good explanation of this from the following link.. I think I understand the concepts until I get to the quadrature encoding and then I get a little bit lost... However, even if we did get 4x the resolution using this technique (12 pulses * 4 points on the PWM to check), we would still only have 48 times that the hall sensor would signal the micro controller within a revolution, and we need at least 360.

On the Amazon product page it states that the motor's PPR is 12, but then it goes on to say that the PPR is 828 after accounting for the gear ratio. What exactly is the real PPR of this encoder which can be read by the digital input? :confused:

The encoder is attached to the motor shaft. For every full rotation of the motor shaft, you will get 12 pulses. But it takes 69 rotations of the motor shaft to get one full rotation of the output shaft after the gear box. Since your curtain will be attached to the gear box output shaft, it is that shaft's rotations that matter to you. So although you can only position the motor shaft with an accuracy of 30 degrees, that is irrelevant. You can position the gear box output shaft with an accuracy of 0.43 degrees.

Rather than "you can position", I should say "you can determine the position". Although I do have experience with using this sort of motor, I don't have experience with precisely positioning them, so I can't say what will be involved there. You would likely want to use PID for the best positioning accuracy. If you just count the number of pulses and brake the motor when it hits the position you want, it will overshoot. That wasn't a significant problem for my application (which only needed speed control and rough positioning), so I never went beyond that.

i agree - do you need to be able to position the motor or output shaft with a resolution of 1 degree?

Proportional, Integral derivative (PID) attempts to control something (velocity, position, timing) by measuring the something, it's rate of change and the integral of the error.

relative position can be determined by counting encoder events from a known position. Of course, waiting to reach a target position and then stopping/braking/reversing the motor when that position is reached will result in a lot of overshoot.

measuring the rate of change in position (D term), velocity (speed and direction), and adding it to the position is a useful approach that anticipates reaching a target position and stopping/braking/reversing before hand. It would stop (remove power), power to the motor before reaching the target, at least resulting in less overshoot. Choosing the correct coefficients for the P, I and D terms is important for smooth operation.

Of course opposite voltage would be applied to the motor when it overshoots. If the motor slows so much that the sum of the P and D values is now short of the target, power would be re-applied but as the motor speeds up, quickly shut off.

ideally, the resulting PID value, the error, is the voltage applied to the motor, but there's a limit of how low you can apply a voltage to a motor before it stops and a different value for when it would starts.

the I component is less important with digital and positioning. If you were trying to maintain the speed of a motor using the PID error to control the voltage, a voltage of zero wouldn't make sense. The I, integral term integrates a fraction of the error which results in a non-zero PID output when the target speed is reached that allows the output to maintain a voltage to maintain speed.

and finally, the PID output is signed, which means it controls both the motor voltage (speed) and direction (polarity). this allows not just braking, but controlled resistance. In this thread they overlook this and this was a problem at work. At work, letting the math do the work solved the problem (precision timing control).

but determining PID coefficients and dealing with non-linear voltage control of a motor is problematic. accepting some limited amount of error may be necessary. At work, some outside consultation suggested PID is difficult.

On the Amazon product page it states that the motor's PPR is 12, but then it goes on to say that the PPR is 828 after accounting for the gear ratio. What exactly is the real PPR of this encoder which can be read by the digital input?

12469 = 3312 quadrature transitions per output shaft revolution which can be read by digital input. There are algorithms to read only 1/2 or 1/4 of the available transitions.

A lot of people confused PPR with CPR, so that 12 figure may mean 4 PPR, 12 CPR. That's more likely for the style of encoder used as a 4 pole-pair disc magnet is much easier to make than 12 pole-pair.

PPR means pulses per revolution, which is always 4 times less than the max counts per revolution for quadrature.

If you want active position control, use PID loop (closed loop control). A simpler approach (open loop) is to go full speed till a given count is reached, slow right down and go till the final count is reached. A little bit of experimentation will get you suitable values.

Only closed-loop control can hold position against a varying force. Here you don't need this I think, its a curtain!

BTW with only an incremental encoder like this you will need some way to home after power-up.