1

What I'm wondering what is the update rate of each GPIO when used as inputs. What I'm actually doing with the Raspberry PI 3 is a pulse counter. I basically have 7 GPIOs set up as inputs and registered a callback to the Rising Edge with python and the RPi.GPIO module, using the following:

GPIO.add_event_detect(x, GPIO.RISING, callback=self.on_pulse_received, bouncetime=5)

Where x is the GPIO pin number. With this setup I'm having some problem on some specific pins: for example, the GPIO pin 4 seems to lose some pulses now and then, while the 26 doesn't. I repeated a lot of tests with more than 3000 pulses and almost every pin had a very low error percentage (about 1.2%), while the GPIO 4 went up to 15-20%.

The pulses I'm reading have a frequency of 1-2 pulse per second and the signal width is 100ms.

What I'm wondering is if there's some pin "internal" priority which makes some GPIOs slower and less reliable the others. If there is I can adapt my code and use different pins to get better performance.

EDIT: I don't know if it matters or not, but my pulses happen at the same time on all 7 GPIOs (just for testing purposes, in real cases it won't happen).

SECOND EDIT: I also have a piece of code which I made to prevent false detection (which happened a lot in the beginning). When the add_event_detect fires its event, I make a double check in the callback just to be sure I detected a real pulse. What I do is the following:

  def on_pulse_received(self, channel):
        time.sleep(0.001)
        if GPIO.input(channel) == GPIO.HIGH:
            # Code to handle the pulse

This way, if the event fires for a false pulse, it's not registered. May this code break the pulse detection ?

  • As joan says there should be no errors at that rate (pulse is 1/10th second, only a few per second). If there are, you've done something wrong. – goldilocks Jan 16 '17 at 13:35
1

You should have a zero error rate on all the GPIO at the data rates you mention.

GPIO4 is not special, but it is significant it is the default 1-wire bus GPIO which can confuse the issue if 1-wire is enabled. Make sure the following command shows no active entries.

grep "w1" /boot/config.txt

http://abyz.me.uk/rpi/pigpio/examples.html#Python_monitor_py will pick up all the pulses.

  • The shell command gives me no output, so I guess that's not the problem. I added a second edit to explain better my detection code, may it be the problem ? – Andrew Jan 16 '17 at 14:11
  • @Andrew Firing all GPIO at the same time will probably make missing pulses more likely with RPi.GPIO but even so I think it shouldn't be as bad as you see. If my pigpio module doesn't pick up all the pulses that would suggest a wiring fault. Your workaround may well be making the situation worse. – joan Jan 16 '17 at 14:22
  • I'll try pigpio and I'll make you know if it gets better – Andrew Jan 16 '17 at 14:22
0

Sorry for the late update, I've been busy at work. Anyway, after some testing and changing to the code I'd like to share with you what I found. Apparently the "missing impulses" weren't caused by the Raspberry being unable to catch them. For what I could understand it was caused by the the the double check I made after the add_event_detect() method call. As I edited in my question, I used to make a double-check in the callback event, where I simply tested if the GPIO was still HIGH when the callback was fired. Apparently, sometimes, the GPIO wasn't HIGH in that moment and so it was recognized as a false-impulse and ignored.

Changing my code to a polling cycle where I manually tested my GPIOs (and implemented some algorithms to avoid noise) solved my problem with my Raspberry now being able to catch every impulse I receive on every GPIO.

Some thoughts: I don't know if what I'm going to say is how things really work in the RPi.GPIO lib, but this is the idea I made after this experience: what I think was happening is that the callback registered in the add_event_detect function was fired some time after the hardware detected a change to the GPIO pin. For this reason, if I double-checked the GPIO state after a period of time it could happen that in that moment the signal was already gone, resulting in a LOW state on the port and so in an ingore of the impulse. My pulses have a medium width of 90ms, so they aren't that short, but this is everything I could figure out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.