I am using the Jetson nano GPIO to read the output of an AB bi-phase rotational encoder encode, I wrote a simple python script to trigger a rising edge interrupt, the callback function prints the current state of the pin that triggered.
import time
import Jetson.GPIO as GPIO
# Define the GPIO pins for the rotary encoders
PIN = 13
# Initialize GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(PIN, GPIO.IN)
def callback(PIN):
print(GPIO.input(PIN))
# Add event detection for rising edges on all encoder pins
GPIO.add_event_detect(PIN, GPIO.RISING, callback=callback, bouncetime=1)
try:
while True:
pass
except KeyboardInterrupt:
pass
# Clean up GPIO
GPIO.cleanup()
After a lot of debugging and many many tries, I stopped using the actual encoder, I’m using a function generator set to output a 3.3v 500hz square wave on pin 13 on the Jetson nano. The output I expect should a stream of ones, but the actual output is random mix of ones and zeros.
I can’t actually download JP4.6.3, Trying to download it from Here Jetpack 4.6.3 only downloads 4.6.1, And even with that version, I keep getting the same result
First I want to apologies for taking so long to reply as I didn’t have my jetson with me lately.
Regarding the script I attached it in the original question.
The exact steps I took on a fresh new Jetbot installation were exactly as follows:
install pip
install Jetson.GPIO
Create a new Python file in the documents folder with the script I attached previously
Open path in terminal and:
python interrupt_test.py
My logic is that since the Callback function triggers only when the interrupt detects a rising edge, and the callback function only job is to print the state of the of the pin, it must print high or 1.
@mohamed.t.keshk you are getting zeros on occasion because by the time the callback function is called and the: print(GPIO.input(PIN)) is executed you are already in the second part of the cycle where the voltage is 0v.
With 500 hz you are 1 ms high and 1 ms down, which tells you that the callback takes some time to get called and so forth and by then you are already at zero. Mind that you are still detecting the rising edge, but your print comes later than you would expect.
I actually though about that, I know it for a fact that the GPIO sampling rate is around 50Khz, and I measured the cycle time of my code to find out that it is running at a minimum of 80KHz.
To sum it, the jetson should be fast enough to detect a frequency as slow as 500Hz and should be able to call the callback function before the signal changes state.
On the other hand, if that is actually is the case; shouldn’t there be a pattern where the callback function prints zeros regularly!! which is not the case. And if that is actually true, what is the most reliable way you can detect and compare between such signals for the application of an encoder.
The key word is sometimes, you are getting a slow reaction some times. This is not a deterministic/real time system that is why is not consistent, it will never be.
The right way to test interruptions is to count them, if you could manage to for instance send 1000 pulses and then in your program you detect 1000 then you know you are good.
Forget the sampling rate on the nano, reaction time of the callback is slower than that.
Remember that probably, you are detecting all the pulses anyways, you are just not arriving on time to print a 1…sometimes :)
I get what you are saying. I just can’t prove that, as I told you I measured the cycle time of the script and it finishes printing long before the pulse ends and switches low.
But how can I compare between two interrupts. My main issue as I wrote in the first question is that I am trying to read a the output of an AB bi-phase rotational encoder, this encoder has two outputs, whichever fires first marks the direction of rotation, and the number of the pulses is the number of rotations (divided by 17).
Maybe I can set a flag at 1000 pulses for example and whomever reaches that mark first is the leading and that marks the direction!!
