obtaining frequency in fpga

[guilio_2008]

I am trying to get a frequency of a signal in FPGA but am having trouble doing so.  I noticed there was a VI that will give you the period, however, I wasn't able to get this working and it also took an hour for it to get onto the FPGA.  Was wondering if anyone had a simple code or know of a way I can get the frequency?
 
Thanks,
guiliio_2008

[JLewis]

What kind of signal are you measuring? If it is relatively clean with a strong fundamental frequency (e.g. sine, square, triangle wave or the like), the Analog Period Measurement is the recommended technique. Please clarify what problems you had using it. The long compile time is pretty much unavoidable for FPGA in general--are you seeing the Period measurement specifically causing a big increase in compile time? You definitely want to do as much verification as possible either in emulation mode or under My Computer, and defer the compile until you are happy with the results you're seeing on the host.
Jim

[guilio_2008]

 I am using a sine wave, of 1 Hz straight out of a function generator so the signal is clean.  I am needing to get the freq for up to 1000Hz.  I tried the Analog Period Measurement, but after the compile and the vi started, it didn't get me any results.  Just 0's.  The only thing I had was the signal going in from my 9215, and a indicator on the analog period measurement vi.  I'm not sure if I had a setting wrong or not.  If there is an example code, I appreciate if someone could post it. 
As for the increase in compile time, I though it was because of the analog period vi.  Since some of these vi's had sub vi's under them, that it was to do the programing for everything.  Thats mainly why I want to go a different route and not use the APM vi but I can do that later.  If I can get the APM vi to work, I'll use that for now.
Now going to the emulation mode I wasn't able to select using target hardware I/O.  It will only allow me to select random numbers.  Any idea why or how I can get around that?
Thanks for your help,
Travis
 Message Edited by guilio_2008 on 08-07-2008 07:27 AM

[JLewis]

Hi Travis,
 
The Period measurement has an output valid signal that goes true only once per measurement, so either you are missing the valid measurement or it is not completing before the internal counter overflows (due to too many samples acquired in one signal measurement). If that is the case, you can reduce the "Number of periods" measurement time or sample at a slower rate. LabVIEW 8.6 provides a "timeout" output to indicate when this happens. There is a Measuring Signal Period - cRIO shipping example that demonstrates how to use the output valid signal to latch each valid measurement result so you can read it from an indicator via the FPGA interface. Use Help>>Find Examples and search for "Period".
 
cRIO doesn't support hardware I/O emulation. I would replace the I/O with a Pt by Pt signal generation VI for testing purposes to play with the Period measurement until you figure out how it behaves. Make a copy of your FPGA VI, move it to My Computer, replace the I/O with a Pt by Pt Sine Generator and see if you can get the measurement working. You'll need to be careful about the timing, though. The important thing is to make sure you have the same number of samples/cycle in your host experiment as you would on the FPGA. LabVIEW 8.6 allows you to do this more seamlessly by letting you write your own VI to generate data when in emulation mode (sorry for the 8.6 plugs, but that's what I've been working with lately :-)  ).

guilio_2008 wrote:


As for the increase in compile time, I though it was because of the analog period vi.  Since some of these vi's had sub vi's under them, that it was to do the programing for everything.  Thats mainly why I want to go a different route and not use the APM vi but I can do that later.  If I can get the APM vi to work, I'll use that for now.

I don't understand what you're saying about the subVIs here. We would like the APM to cover as many use cases as possible without needing to modify it. But it is designed to be cracked open in case you do need to customize things. I would love to hear what you changed when you get to that point, so we can evaluate whether we need to add (or subtract) some features to make it more useful.
 
Jim