FPGA counter jittering/flickering

[vandej]

Hello all - 

Background:

I have recently been getting into working with NI's FPGA hardware and am running into some difficulties in the attached code I inherited. I have tried to add a counter to the program to calculate the trigger frequency in the labview/host program itself. The host FPGA program is just a simple state machine that I query every ~50 ms and run occasionally to update values or arm or disarm the trigger.

Problem:

My counter works sometimes but has a very regular (I can see the display change ~once per second) of jittering/flickering while the trigger signal is very consistent, even when using a pulse/delay generator.

I am wondering if someone can just look at the counter portion of my code and either point out an error or recommend a better way to get a nice steady frequency from this. I did look through the forums and through NI tutorials and help files, in fact I pretty much copied one of their help files for my counter, but haven't been making much progress.

A few details:

LabVIEW 2010 SP1

Windows 7 and XP 64-bit

FPGA PCIe-7841R

Trigger signals are generally 5V/TTL pulses

Thanks,

Jeremy

[srm@viewpointusa.com]

nothing obviously wrong with the "Cycle Time" section of your code.

if will time from rising edges of "External Trigger In".  the cycle time is limited to 107 seconds before the counter rolls over.

by flicker, do you mean different, unexpected values?

you can cascade a couple latched values to see the last few cycle times.  that may show that you are getting some extra edges you did not expect.

ortry to put an edge counter to see the number of edges to see if it agrees with what you expect.  if you are expecting 10 Hz, the edge counter should be increasing at 10 hz.

if you need to deglitch the input, there a couple easy ways to do that

[vandej]

Hi Stu -

Thanks for the quick response. I tried two things.

1 - I recorded an array of values coming from the FPGA (see attached). Out of ~250 values 10 were off (however, in the past we have seen the jitter be much more frequent than this). The values I am expecting are on the order of 666666 +/- 200 ticks/cycle. There are two different values we are not expecting: 1) the off values that are way off by 53XX ticks/cycle 2) the 661XXX values are also off by more more than we would expect. 

2 - I am using this for two different projects and the one I am currently working on I used a pulse/delay generator to deliver a very clean signal and the counter works great. However, the other test I am not capable of using this pulse generator as I can only do this through a remote connection.

You mentioned there are a couple ways to possibly deglitch the input signal, would this still be possible given the current situation?

Thanks for the help thus far!

Jeremy

[srm@viewpointusa.com]

that data looks a bit strange for noise.  the normal count followed by a short count should be followed by a (normal count - short count), not a normal count.  what is the source of this edge? and how do you know the signal does not reflect the real data?  have you observed the signal with a scope?  if the clean signal generator produces data as expected, i would question the signal you are using and not the code in this case.

since the counter resynchronizes, it does not look like noise yet.  more testing is required.  timestamp each transition and include polarity of bit in MSB.  mask out MSB for analysis.