How to Timestamp A Pulse Using FreqMeasureMulti?

[jIyajbe]

Hi all,

I am writing a program to capture random pulses (muon pulses from cosmic rays) from four high-speed comparators (a TLV3501), input into a Teensy 4.1. The pulses arrive at random time intervals at an event rate of ~2 counts per second, and pulse width in the range of 50ns - 500ns. I am using FreqMeasureMulti, and it is measuring the pulse width quite accurately. My next task it to timestamp the rising edge (or the falling edge, either will work) of each and all of the pulses. In a thread from 2021 (https://forum.pjrc.com/index.php?threads/t4-isr-handling-confusions.68470/#post-291546), Paul Stoffregen said,

"...using FreqMeasureMulti...uses timer hardware [and] captures a timestamp at the moment the pulse happens, regardless of interrupt latency."

My question is, how can I access that timestamp? Does the FreqMeasureMulti library expose it somewhere? (I looked, but didn't see anything.) Or is there some other way to obtain that value?

Thanks in advance!

--jIyajbe

 

[Rei_Studio]

Looking at the current library source on GitHub (FreqMeasureMulti.h and FreqMeasureMultiIMXRT.cpp, the Teensy 4.x version), I don't see a call that gives you the absolute capture time. The public functions are begin, available, read, readLevel, countToFrequency, countToNanoseconds and end. In the ISR the code stores "capture - _capture_previous[edge]" in the buffer, so read() returns the interval, and the absolute capture value only lives in the private _capture_previous array.



One idea I haven't tested: if every edge ends up in the buffer, adding up the successive read() values would give you a running time since begin(), in timer counts. That only works if no event is dropped. The buffer holds 24 records, and the code skips an entry without any warning when the buffer is full. The sum is also 32 bit, so it will wrap eventually.



If you need a guaranteed timestamp for every single pulse, you may have to read the capture value yourself, or use a modified copy of the library. That last part is a guess on my side.

 

[jIyajbe]

Thanks for your reply. Yes, I need the timestamp for every pulse. I came to the same conclusions (the library doesn't make the timestamp available, so modifying the library is the only plausible way to obtain it), but I don't really trust my opinions; I am an extreme amateur at coding, and I know next door to nothing about register-level programming.

As a consequence, I have been enlisting the help of an AI to help me understand what is going on in the FreqMeasureMulti library, and trying to come up with minimal changes to it that will enable the pulse arrival timestamp to be readable by my code. Its proposed changes *seem* plausible, but I have little trust in AI-sourced code. I am going to test the changes thoroughly before (diffidently) offering them up to this community.

 

[jmarsh]

Couldn't you just use FREQMEASUREMULTI_INTERLEAVE mode to get times for both rising and falling edges? Keep a running accumulator to get the time since 0.

 

[jIyajbe]

@jmarsh: I'm not sure that gets me the times the pins went HIGH or went LOW; if I am understanding the description of INTERLEAVE correctly, that would give me two time *intervals", but not the absolute clock time:

FREQMEASUREMULTI_INTERLEAVE -> A new value becomes available at each rising and each falling ramp and contains the time since the previous similar (rising or falling) ramp.

However, your question caused me to re-think what my actual question/goal is, and to state it more clearly: What I actually need to know is: Suppose two (or three or all four) of the Teensy pins (detector channels) go HIGH within some (user-chosen) time interval. What I need to know is (a) in what order each pin went HIGH, and (b) what the time intervals were between the moments each pin went HIGH. (EDIT) So, for example, if channels 1 and 3 both go HIGH ("two-fold coincidence"), I need to know which of them went HIGH first, and I need to know the time interval between when the channel 3 went HIGH, and when channel 1 went HIGH. If all four channels went HIGH ("four-fold coincidence"), I need (again) to know the order in which they all went HIGH, and I need to know the time intervals between all of the "going HIGH" events.

I reckoned that I could determine both of these if I could capture the peripheral clock count values for each pin. However, if there is another way to accomplish this...???