Tow edge separation with missed pulse detection

[mzema]

Hi guys,

I am trying to find solution for my two edge separation measurement, where I count on some missing pulses. I have one reference highspeed sensor and one UUT. Of course, at some speed UUT starts to miss some pulses and since two edge separation measures only time delay between first rising/falling edges, delay would be constantly rising to the maximum value, since counter does not know that there are missed pulses. I would like to somehow skip over that pulse which was not detected by UUT, because I know the frequency => time period for this signal. Can I somehow analyze this delay and if the delay is for example bigger than 500 us, I would simply skip next pulse from reference sensor?

Thank you in advance for any kind of help 🙂

Martin

[Henrik_Volkers]

Sorry, not clear to me, what do you want to measure?

Where is the information you want to extract?

[mzema]

It is measurement of sensor switching reliability. Two edge separation measurement first triggers on first channel rising/falling edge and then waits for second channel rising/falling edge. But there are cases where UUT miss the switch, therefore it would returned delay from pulse where UUT did not switched its output and delay would be constantly raising with every missed pulses. I want to record those missed pulses and skip it, so I can measure delay only where UUT was able to switch its output. Of course, there should be some condition/range of delays, which are considered as successful switches.

Hope now it is more clear. If not, please let me know what info you are missing.

Martin

[Kevin_Price]

Within the task definition, no you can't configure a counter to buffer short, expected intervals while rejecting long intervals.  You can only do this with a post-processing step, where it should be pretty trivial to handle.

-Kevin P

[mzema]

Well the delay will be consantly growing with every missed pulse then, so I am little bit worried, if this is not the problem and if this will not cause buffer to overflow :-/.

[Henrik_Volkers]

I'm not a counter expert, but how about configuring two counter

C1: start (with zero) on pos. ref slope , stop on pos. UUT slope

C2: start (with zero) on neg. ref slope, stop on neg. UUT slope

reading arrays of C1 and C2 values

But as noted I don't know if it's possible to configure your counter in this manner.

If C1 (or C2) time is greater than Ref periode ticks  you have a missed pulse, check C1 and C2 missed counter should match 😉

with the rest of that data you can measure all statistics   (mean, range, jitter, .... )

Or have 4 counters free running (same start, same clock) each triggered read on pos&neg slope of ref&UUT.

(Producer)  

the REF counter value next smaller to the UUT give the delay. Postproceesed 😉

so you crawl along the UUT values , detect missing pulses and track the ref value array position..

[Kevin_Price]

---

@mzema wrote:

Well the delay will be consantly growing with every missed pulse then, so I am little bit worried, if this is not the problem and if this will not cause buffer to overflow :-/.

---

I don't think you're in danger of buffer overflow in your task due to an occasional failure of the UUT to respond to a reference pulse.  And the extra long invalid measurements seem pretty easy to identify and ignore.  The only thing left is that when the UUT fails to respond to 1 pulse, you'll lose out on 2 potential measurements.  For example, if the UUT doesn't respond to the 5th pulse, your 5th measurement will be the time from the 5th reference pulse to the 6th UUT pulse.  You'll have to ignore this one, meaning that you'll miss out on measurements for reference pulses #5 and #6.

A version of Henrik's suggestion could let you capture timestamps for all the edges from reference sensor and UUT which you could then post-process to find all available response times.  It'll be a lot more work than the 2-edge task you've got now, and you'll only gain 1 of the 2 missed measurement opportunities for each time the UUT fails to respond.   You'll have to decide if the extra effort is worth the little bit of extra data, I can't tell from here.

-Kevin P

[mzema]

Thank you all for suggestions! Really apreciate it ;).

Martin