Teensy 4.0 QDC/QuadEncoder - Sanity check for my application? 5 Mpulse/sec encoder, trigger output signal

[Laogeodritt]

Hi all!

I'm in the early engineering stages of a project, and I'm trying to figure out whether the Teensy 4.0 QDC will be able to handle the motor encoder we're using and our position detection requirements, or whether I need to plan on designing external circuits to do what we need. I think I have a good grasp on it and am just looking to confirm my understanding and figure out a few missing details, so hopefully this is a simple question for some of y'all.

Project context: We are considering using the Teensy 4.0 in a scientific instrument prototype. We will be using a motor whose quadrature encoder is outputting up to 5,000,000 pulses per second at the maximum motor speed (overall, so 2.5MHz on each signal A and B). We want to be able to accurately accumulate the motor position and take stroboscopic imagery, which involves providing a trigger signal at a precise position every rotation to the flash and camera equipment.

I've gone over Chapter 56 of the i.MX RT1060 manual (PDF, as hosted on the PJRC site) and the QDC seems to do more than what we need, all in hardware. From a search on the forums, I discovered mjs513's QuadEncoder library, which I understand is included by default in Teensyduino. (Yay! One of the things I love about using Teensies for these prototype and one-off projects)

My questions are:

* In general, does the QDC peripheral on the Teensy/i.MX RT1060 seem well suited to this task? Am I obviously missing some challenges in this post?
* Is it possible to route the POSMATCH signal to a GPIO output pin (e.g. via the XBAR), or are we limited to processing the event in software? At a glance it doesn't seem like the QuadEncoder library supports that, but that doesn't mean I wouldn't be able to configure this directly in the hardware registers myself.
* What is the "IPBus clock" that section 56.5.1.3.2 (filter) is talking about? Am I correct in assuming it's ipg_clk_root, and that this clock is 1/4 of the system clock (i.e. at an ARM clock of 600 MHz, this would be 150MHz)?
* I don't have too much experience with motor encoder noise/filtering at this speed. With our 2.5MHz A and B signals, presuming the 150MHz IPBus clock is correct, does this seem realistic to filter? With prescaler of 1, that seems to give us minimum 60 clock cycles per pulse on each of A, B, which I think gives more than enough leeway to play with number of samples or sample period.
* Is the Teensy 4.0's GPIO happy to handle a 2.5MHz+ digital input signal? I haven't really worked with digital signals over 1MHz with Teensies or other microcontrollers, and I'm not sure if the GPIO input circuitry might have practical limits below the QDC filter clock limits. (With the Teensy's internal clocks as fast as they are, are my expectations just way too low for its GPIO circuitry...?)

Thanks in advance!

Laogeodritt

(P.S. I really appreciate a traditional, web-searchable forum still being around. I've figured out so many of my problems or implementation challenges with Teensies thanks to searchable threads on here. Thanks for continuing to run it!)

 

[jmarsh]

* In general, does the QDC peripheral on the Teensy/i.MX RT1060 seem well suited to this task?

It's designed specifically to handle quad encoders, so yes.

* Is it possible to route the POSMATCH signal to a GPIO output pin (e.g. via the XBAR), or are we limited to processing the event in software? At a glance it doesn't seem like the QuadEncoder library supports that, but that doesn't mean I wouldn't be able to configure this directly in the hardware registers myself.

The hardware definitely supports it - the QDC POS_MATCH signals for QDC1-QDC4 are xbar inputs 60-63. So you'd need to pick a pin that's usable as an xbar output, use xbar_connect to route them to each other and set the appropriate CORE_*_CONFIG for the output pin so that its mux is set to the xbar.
Note that if need be, you can also xbar the POS_MATCH signals into a quad timer if you wanted a timed response.

* What is the "IPBus clock" that section 56.5.1.3.2 (filter) is talking about? Am I correct in assuming it's ipg_clk_root, and that this clock is 1/4 of the system clock (i.e. at an ARM clock of 600 MHz, this would be 150MHz)?

Yes, the IP Bus is generally 1/4 of the cpu clock. My recommendation is to use 528MHz unless you actually need to extra speed of 600MHz, which gives an IP Bus of ~133MHz.
(600MHz is technically overclocking, and it was recently discovered the internal voltage setting that has been used for years isn't always sufficient for some chips which will push them even higher...)

* I don't have too much experience with motor encoder noise/filtering at this speed. With our 2.5MHz A and B signals, presuming the 150MHz IPBus clock is correct, does this seem realistic to filter? With prescaler of 1, that seems to give us minimum 60 clock cycles per pulse on each of A, B, which I think gives more than enough leeway to play with number of samples or sample period.

This probably needs in-situ testing. There's plenty of room for filtering if you need it, but whether or not stray edges are a problem will depend on the situation.

* Is the Teensy 4.0's GPIO happy to handle a 2.5MHz+ digital input signal? I haven't really worked with digital signals over 1MHz with Teensies or other microcontrollers, and I'm not sure if the GPIO input circuitry might have practical limits below the QDC filter clock limits. (With the Teensy's internal clocks as fast as they are, are my expectations just way too low for its GPIO circuitry...?)

It will be absolutely fine with that speed. It's rock-solid up to about 50MHz and can go much higher with appropriate care.

 

[Laogeodritt]

Excellent. Thanks for the response, jmarsh!

(600MHz is technically overclocking, and it was recently discovered the internal voltage setting that has been used for years isn't always sufficient for some chips which will push them even higher...)

Ah, huh, interesting. Any further reading to suggest on that, other threads here and so on?

This probably needs in-situ testing. There's plenty of room for filtering if you need it, but whether or not stray edges are a problem will depend on the situation.

Yeah, we're expecting to have to test practically to dial in the filter settings, if we need it at all. Just wanted to check that I'm understanding the way this works and that we have the room we need to configure it.