GPIO Riding Edge Interrupt w/ Time Stamp

Hello,
I have a contact closure switch connected to P8_14. When the switch is activated, P8_14 is brought to ground. I need to apply a time stamp when this occurs with millisecond accuracy.

  1. I have an adafruit GPS with 1 pps output. I see the NMEA strings and have confirmed the 1 PPS is working.

  2. I have NTP running with my local GPS and 1PPS source configured. (Maybe chrony is a better choice?)

  3. Just for testing, I am using the following python code:

import Adafruit_BBIO.GPIO as GPIO
import time
import datetime

GPIO.setup(“P8_14”, GPIO.IN, pull_up_down=GPIO.PUD_UP)

#GPIO.add_event_detect(“P8_14”, GPIO.RISING, callback=my_callback, bouncetime=1000)

while True:
GPIO.wait_for_edge(“P8_14”, GPIO.RISING)
ttime = datetime.datetime.now()
print(ttime)

When I compare my time with a very expensive DAQ, my time stamp is always off by 2-4ms and it is not a consistent offset. Does anyone have any other thoughts at to how I might approach this? I am needing to get the timestamp accurate to 1ms.

Use the pps driver, setup an overlay like shown:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-UART4-TESEO-LIV3F.dts#L63-L71

Then you can use the pps/gps tools...

Regards,

Hi Robert,
Thanks for the quick reply. I am already using a custom overlay and
using the PPS/GPS tools...

trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1548882288.001021883, sequence: 3727 - clear
0.000000000, sequence: 0
source 0 - assert 1548882289.001020522, sequence: 3728 - clear
0.000000000, sequence: 0
^C

Thomas:

You are at the limit of a combination of the OS and Python response time.

I think you will also find that the absolute accuracy of the internal time base in the BBB, set by timesyncd (or optionally ntpd) will meander +/- ten milliseconds across several hours.
(Put the 1PPS output from a GPS into the port and plot what happens to the time stamps over a 24 hour period.)

Depending on your requirements, I suggest you consider something like a “TICC” for the edge timing capture, it will provide a serial stream with the time stamps, easily read by the BBB via the USB port, that has relative accuracy into the 100 ps range, and absolute time a function of the 10 MHz reference signal you give it.

https://tapr.org/kits_ticc.html

Your other alternative is to write some code for the PRU’s that can do edge capture in real-time, then hand off the results to the BBB main cpu.

So, depends on your need to trade off money versus your time.

— Graham

Graham,
Thank you for your input. I have reached out to inquire about the
TICC kit and am awaiting a response. I don't mind spending some money
if I need to in order to accomplish this task. If I were to utilize
the PRU's, how would you envision this working. (I have zero
experience here).

Once we detect the leading edge of the contact closure switch, how
would we get a time stamp? I assume there is a fixed 200,000,000
cycles per second on the PRU. Is this constant or have drift? I am
wondering about detecting the leading edge, then counting the number
of cycles until a 1 PPS signal is received. Or is this way over
complicated?

Looking forward to hearing your thoughts...

On Wed, 30 Jan 2019 16:08:48 -0600, Thomas Remmert
<tremmert@snaggleboards.com> declaimed the
following:

Once we detect the leading edge of the contact closure switch, how
would we get a time stamp? I assume there is a fixed 200,000,000
cycles per second on the PRU. Is this constant or have drift? I am
wondering about detecting the leading edge, then counting the number
of cycles until a 1 PPS signal is received. Or is this way over
complicated?

  Would require much study, but possibly make use of one of the system
timers? Timer configured to restart on the 1PPS (presuming they can be
scaled to run just >1second) and read the timer count on the detection of
the switch closure -- that would give ticks since last PPS... Keeping track
for full date/time with the PPS might be an adjunct operation (both maybe
done with a PRU to ensure no OS latency)

Thomas:

If you are interested in the PRU, download Professor Yoder’s (free) book from:

https://markayoder.github.io/PRUCookbook/

The PRU is a small real time processor running at a clock speed of 200 MHz, derived from the main clock tree in the BBB.
So, you won’t get resolution of 200 MHz clock, but something more like the time of the fastest loop running on a dedicated 200 MHz processor that will count and report what you are looking for, so if the loop was 20 instruction clock cycles long, you could get 10 MHz or 100 ns resolution.

Dennis also makes a good suggestion, in that there are “capture timer” pins on the BBB that I have seen used for capturing/time-stamping GPS 1PPS signals, for use in an NTP server.
I am not aware of any python drivers but if you are capable in “C”, there is sample code around to run those pins in “capture timer” mode in “C”.

The TICC will do exactly what you described, you can control it from Python running on the BBB as a (USB) serial slave peripheral. But it is another $190. You will also need a reasonably precise 10 MHz reference for it. Either your lab reference, or you can buy another kit called the “Pulse Puppy” from the same people that sell the TICC.

— Graham