How to read rotary encoder signal with AGX Xavier

I would like to use my AGX Xavier to read the signal of a rotary encoder in a subprocess and trigger inference accordingly in another subprocess. However, I wonder if the board can keep up with the signal at all. Right now I’m using the GPIOs and Python scripts, but when the signal is fast it seems to lose some data. Are there any other ports (a trigger signal perhaps) to do this?
Another way may be to read the encoder signal from a microcontroller and trigger the AGX after a certain distance (= a definite number of peaks) has been reached. Still, I need a trigger port on the board and I fear that using the GPIOs may be unreliable.
What can I do?

Hi,
This would need other users to share experience. In userspace, one general solution for IPC is unix socket. May give it a try.

I doubt GPIO will be reliable. You might find something which converts from quadrature encoding to serial UART (or serial UART over USB). I don’t know much about actual hardware to recommend, but here is an example:
https://www.adafruit.com/product/3727

Yeah, I thought as much about the GPIOs being unreliable. Maybe I can reprogram a GPIO_CLK for this purpose and use it as a trigger input? Those pins may be faster than other GPIOs, maybe…
The easy solution is of course to use a micro to read the encoder and then read the pre-processed signal which runs at a way slower pace (for example, the micro itself could output a peak every 10-20 cm). I’ll go for this option if the Xavier cannot be used for this task!

Having a “strobe” clock usually helps in such matters, but it also requires being able to slow down to strobe only when timing is known to be valid. If you are turning a rotary encoder by hand, then it is unlikely you can do this. Should this be something automated, e.g., a powered table movement on a milling machine, then it might work consistently, but might still require slowing down. An external circuit which has a buffer and converts to serial signal, or else converts to serial and goes to something else which is in turn buffered, won’t have that issue. I personally wouldn’t invest much time into a well-behaved GPIO, especially when more than a single bit must work in time with a second bit.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.