This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is there a speed/frequency limitation for the encoder?

Other Parts Discussed in Thread: TMS320F28069M, DRV8305

Hello,

I am running a motor with encoder using LaunchPad TMS320F28069M with BoosterPack DRV8305. As long as the motor spins not too fast, everything is working so far. However, when I increase speed, at some point the encoder starts to miss counts. As a result the motor gets slower or even stops while there is maximum current applied (I guess because the error between perceived and actual electrical angle gets too high).

First I thought my encoder was just bad, but after switching to a different encoder, I still see the same behaviour and it seems to always occur at the same encoder line frequency:

1. Encoder: 20000 lines
Already starts to miss a few counts at lower speed but significantly increasing at 900 rpm.

2. Encoder: 5000 lines
Now the motor runs up to 3600 rpm but then again misses lots of counts.

I noticed that with the second encoder, the maximum speed increased by the same ratio by which the encoder lines are reduced. It seems like the problem is occurring at a line frequency of 300 kHz. Both encoders should be able to deal with much higher speed according to the datasheets.

Is there a limitation in the hard- or software that explains this? If yes, is it a fixed limit or is it dependent on some settings?

Best, Felix

  • Hi Felix,

    What GPIO qualification settings are you using for the eQEP input pins?  (GPxQSELn)
    - Please note that asynchronous qualification is not supported when used with the eQEP.  The F2806x errata document describes this.
    - If you are noticing that the signal between the encoder and C2000 is not completely clean, you can utilize higher levels of GPIO qualification to digitally 'filter' the signal before it goes to the eQEP peripheral.  Obviously, you do not want to use too much qualification as it will adversely effect the measurement.


    Thank you,
    Brett

  • Hi Brett,

    Thanks, I did not know about the GPIO qualification filter. This was indeed the problem!

    I checked the settings in hal.c, with the default settings the window width of the filter is 0.96us. When spinning the motor with 3600rpm, the pulses of the 5000-lines-encoder are just around 0.8us long and therefore get filtered out.

    After reducing the qualification period, I can run the motor at full speed now, without missing encoder counts.

    One question about this: What are the default settings of the qualification, is it also running for pins where nothing is explicitly set in HAL_setupGpios()? I ask because it seems that the period can only be set for blocks of GPIOs and if I change it for the eQEP pins, it will also affect some unrelated pins. I wounder if this can have some side-effects. Qualification is not explicitly set for any of the other pins, though, so maybe the filter is not active for these pins anyway?

    Best, Felix
  • Hi Felix,

    I'm glad to hear that things are now working.

    If not explicitly changed, a register will be put into its reset state when the chip is powered on.  If you look at the TRM/peripheral user's guides for your device, the register descriptions provide what the reset value is for each bit. 

    You can then confirm your expectations, by looking at the value in the watch window after you've started to run your code.

    [In the case of GPAQSEL1, you will notice that Figure 1-67 shows that GPIO15 is a bit that can be read or written.  You will also see that this bit is set to 0 after a reset]


    Thank you,
    Brett

  • I found it, thanks a lot again!