0

I'm currently using a RPI2 b running linux to check for when a pulse is received from an arduino (3.3v). Something to note is that I'm also reading data from uart and writing it to a file at the same time.

On boot I start my script using screen.

I collect my uart data into a queue and then write into a file when available. Every time I receive a pulse I add a mark into a queue that is writing,when available, to the same file as the data collected from uart.

The pulse is held high for 30ms.

Below is my setup code.

GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

def pulsed(channel):
    state.pulsequeue.put(chr(254))

GPIO.add_event_detect(17,GPIO.RISING, callback=pulsed)

For some reason I'm not recording every pulse all of the time. I've checked this by incrementing a variable each time I enter the pulsed loop and comparing it to the number of times the arduino actually sends the pulse. I'm sure that the arduino is actually sending the pulse.

Is there a chance there is a problem with the duration of my pulse or am I just catching an exception where the interrupt is taking lower priority than one of the other operations happening?

  • 1
    How many and how often do you miss pulses? There is nothing in your snippet to suggest a problem. – joan Jan 6 '17 at 16:38
  • Have you tried adding a capacitor or increasing pulse duration? – Mohammad Ali Jan 6 '17 at 22:56
  • @joan It depends on the run. It's usually about 1/12 I would guess sometimes less sometimes more. There really doesn't seem to be a pattern that I can recognize. – Mathew Wright Jan 9 '17 at 16:52
  • See if the pulses are picked up with abyz.co.uk/rpi/pigpio/examples.html#Python_monitor_py – joan Jan 9 '17 at 19:20
  • @joan Trying this now thanks I'll let you know how it goes thank you. – Mathew Wright Jan 9 '17 at 20:34
0

I have had this exact same issue, although I do not know fully understand why the raspberry pi GPIO fails to register the rising edge on certain occasions. I took these three measures to correct for it.

1) It looks like you are doing this in Python, so I put the rising edge detection code inside its own thread.

2) I added a 1uF electrolytic on the signal line to smooth the transition, making it more likely to be registered.

3) The less elegant solution, I mirrored these connections to other GPIO pins- In your case you would need to modify your Arduino code to output this pulse on multiple lines and then connect this to the RPI.

I have a feeling it is to do with the operating system specifically the polling intervals and resource management. You could also elevate the priority of the Python program by using "renice".

  • Note that according to the manual entry for renice(5): "Users other than the super-user may only alter the priority of processes they own, and can only monotonically increase their 'nice value' (for security reasons) within the range 0 to PRIO_MAX (20), unless a nice resource limit is set (Linux 2.6.12 and higher). The super-user may alter the priority of any process and set the priority to any value in the range PRIO_MIN (-20) to PRIO_MAX. Useful priorities are: 20 (the affected processes will run only when nothing else in the system wants to), 0 (the 'base' scheduling ,..." – SlySven Jan 6 '17 at 17:28
  • ..."priority) anything negative (to make things go very fast)." This means you have to be root to elevate the priority of the python or any other process. – SlySven Jan 6 '17 at 17:29
  • 1
    I have never seen this problem with my pigpio Python module. – joan Jan 6 '17 at 17:57
  • "specifically the polling intervals..." -> The GPIOs have actual hardware interrupts associated with them, so there is no software polling that should be going on with this in either kernel or user space. If there is, it is a poorly written userspace library. – goldilocks Jan 6 '17 at 18:28
  • You can try any of the above methods and find which one works for you, I did not have time to sit there and experiment each one as I was short for time, instead I did a brute force attack. Perhaps someone can explain which is the correct solution. I have a feeling its more of a signal condition issue more than any of the other methods involving messing around with the code. – Renegade243 Jan 7 '17 at 11:51

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.