DRV10983 MotorSpeed/MotorPeriod register values

Hello Martin,

DRv10983 is sensor-less device, so motor speed and period is derived by detecting zero crossing of phase U back-emf, calculated internally.

Any sensor-less calculation will have few % of error tolerance with actual speed, as I see the motor period register readings are very well with +/-1.5% of actual speed (measured by laser). This  is  quite good accruarcy for sensor-less device.

I'm bit confuse why Motor Period and Motor Speed is not matching. I will have to look into this.

Can you tell me how are you reading these values- Via GUI or you have extra mCU on board reads back the value via I2C?

Best Regards

Milan-Motor Application Team

Hi Milan,

many thanks for the fast answer!!

to answer your question: I have designed two different PCBs for different motors with the DRV10983 until now, and I am trying to finish the software for going into production ASAP.

...just thinking about your answer...:

The motor is turning synchronously to the magnetic field the DRV is making by itself.

And the DRV knows very precise at what frequency it let the magnetic field turn, so it should know the turning frequency of the motor also very precise.

I am writing sensorless BLDC driving software since many years now, normally using microcontrollers and discrete transistors, but I never had a problem in calculating the RPM without having sensors. It is easy: if I don't know the PRECISE RPM rate, I can not let the magnetic field turn precise enough to keep the motor turning at the desired speed.

The only part where you normally loose precision is the resolution of the timer that is the timebase of all measurements and calculations.

That means, if you have a timebase of 25kHz , the time resolution is 40usec.

If you have a RPM rate of (to make it easy) 6000RPM, what means 100Hz frequency and 10ms period time, the precision I would expect is 10ms +/- 40usec.

That is 99.6Hz .. 100.4Hz, or, converted to RPM 5976..6024RPM. Or in percent: something around <0.5%. That would be a percent value I can live with.

One more thing I have found in the meantime: The values (frequency AND period) from the registers are always giving a faster RPM rate then the motor has itself.

From the hard- and software I have designed until now I know, that you have to stop driving a coil to have a chance to detect the zero crossing.

May it be, that you internally calculate time and frequency from the last zero crossing up to the time were you stop driving the coil?

That would be an explanation for being allways too fast.

On the other hand: How do you make the signal on the FG pin? That should be absolute synchronous to the motor axis.

I have not checked that, because it is not connected in my PCB design.

I did not connect it, because I thought, I can use the values from the registers. But maybe I have to change my design to use the FG signal if it is more precise.

What do you think? Does that make sense?

The disadvantage is, that I need one more uC pin for that.... and pin count is always short :-)

Thanks for your help,

best regards,

Martin.

Martin,

Allow me to discuss these with system engineer, I will come back to you.

Best Regards

Milan-Motor Application Team

Martin,

In your analysis at 100Hz, timer resolution gives error of 0.8%,  Plus there is error tolerance and jitter in calculation of back-emf zero crossing in DRV10983. DRV10983 is sinusoidal drive, so traditional zero-crossing detection by stop driving coil and sensing zero-cross does not work because all phases are always driving the coils. In sensor-less scheme of DRV10983, back-emf  zero-crossing is calculates by algorithm, which have tolerance and jitter in determining motor frequency and period.

FG pin also will have jitter and error similar to register value, because everything is derived from same calculation. I agree with your decision to save FG pin and use register values to read frequency/period. Finally I would suggest you to use some kind of averaging filter either low-pass or moving-average to get steady reading from register value.  Motor period register is more accurate becuase speed is derived using fix-point division, which can lead to further error.

Best Regards

Milan-Motor Application Team

Hi Milan,

in the meantime I did some more measurements:

As I said, my motors are rotating a high mass, so there is nearly no short time deviation in RPM after spin up.

I have connected the FG pin and a laser to my scope to compare FG signal and real-world rotor position.

You said in your post, the FG signal has also a deviation from physical turning, because it is made by the same algorithm.

My measurements shows, that FG and rotor are perfectly synchronous....

Also I checked the speed and period register values for some seconds and did some calculation:

Laser is saying 2105RPM, constantly over a minute.

Mean value of Speed register is saying: 2235RPM (single values between 2232 and 2236). That is a error percentage of +6.2%.

Mean value of period register is saying: 2136RPM (single values between 2142 and 2129). That is an error percentage of +1.4%.

As you can see, speed and period values from the registers are always too fast. So averaging filters do not help. Any idea why and what to do?

Error of speed value register is over 5%. This is far too bad to by used for anything......

FG signal is perfect. But that needs additional port pins on the controlling uC.

If the FG signal is perfectly synchronous, why are the register values so far away?

All should be based on some internal calculation and measurement as I mentioned before.

best regards,

Martin

Martin,

As I mentioned, use Period register value. It is more accurate than speed register becuase speed is derived by fixed point division so prone to error. My suggestion of Averaging or filtering was to  get stable speed feebdack values, surely filtering can not  help in reducing error to improve accuracy.

On FG signal- Are you saying FG signal frequency is same as 2105 rpm and does not have jitter? Can you share the scope capture? I would to analyse in more details before commenting.

Best Regards

Milan-Motor Application Team

Hi Milan,

please find a little report including the scope picture attached as pdf.

best regards,

Martin

LaserAndFG-00.pdf

Martin,

Thanks for sharing the scope picutre. you are right, FG is more accurate than Period register. I have confirmed same after disucssion with system engineer. My previous statement was wrong about the error on FG, please ignore.

2 factors can cause the error on period register.

1. The period is counted with 10us clock (100kHz), let’s assume the motor is 12pole, which electrical frequency is 210Hz, 5ms. 10us / 5ms is 0.2%. That is pretty small in this case. But for high speed motor, it may cause bigger error.
2. The second error is due to oscilattor trimming. That means the internal clock of DRV10983 could have same error, no matter how accurate we control it. This could be the reason for additional error.

Best Regards

Milan-Motor Application Team