QDEC Peripheral with high speed encoder

[pekon94]

Hello,

I have been testing an encoder using the QDEC peripheral.

The encoder produces 256 pulses per rotation. Testing without any load assigned to the motor, the encoder rotates at 2000-3000 rpm depending on the input.

Using the zephyr sensor api or the nrfx_qdec driver I have not been able to get correct measurements.

I tried lowering the SAMPLEPER to the lowest possible setting (128us) but it didn't work either.

However, using gpio pin interrupts I have been able to get correct measurements.

Is the QDEC peripheral suitable for such a frequency of pulses ?

Is there any other way to do this to avoid using multiple interrupts (like GPIOTE and TIMER as I read somewhere) ?

[ovrebekk]

Hi 

That changes things. Hopefully you only need to detect displacement in one direction? 

You could change the TIMER module to counter mode, and instead of measuring the time between two consecutive GPIOTE IN events simply count how many times each of them occur. Then you can set up a separate slower timer (using an RTC or Zephyr timer) to run a capture on the timer and read out the value at regular intervals. 

As long as you have 2 free TIMER modules, and an additional GPIOTE and PPI channel, you should be able to serve 2 encoders. 

Best regards
Torbjørn

[pekon94]

Hi,

ideally I would need to be able to capture displacement in both directions. 

I was thinking of checking this by capturing the PINB status whenever the PINA GPIOTE event occurs. 

On the other hand, direction is something that perhaps I would be able to exclude considering that I will be controlling the motor's rotation and therefore I can try considering the actual direction equal to the command direction I set (in order to avoid the need for calculating the direction through the encoder). 

[ovrebekk]

Hi 

If you can exclude it it would definitely simplify the implementation, but possibly it is enough to occasionally trigger an interrupt on the PINA event and check the status of PINB. You just need some system to detect if the interrupt is delayed, since this would give you an incorrect reading. 

Best regards
Torbjørn

[pekon94]

Hello,

I can do that considering the direction equal to the motor control direction and use it to calculate the position combining this and the displacement.

Considering this the interrupt routine will only include a counter increase and not any time consuming process.

I will try this and if it works I will update here for the record.

How could I check whether the interrupt is delayed ?

Thanks again.

[pekon94]

Hello Ovrebekk,

would it be a solution to increase the APP core frequency (to 128Mhz) ?