CLOCKS_PER_SEC

[Jim_81]

I am programming a timing function which calculates the frequency of a pulse when I connect to a pulse generator I get the wrong frequency, the period is consistantly 20% shorter than the time it should be between pulses.  Can CLOCKS_PER_SEC be incorrect and if so how can I adjust the variable to make sure it's correct when calculating the time.

[mvr]

The help for clock() states  "This function returns an approximation of the amount of processor time your program has used since it started executing."  It does not seem very likely that it would be off by anything like 20%.  If you are measuring a relatively short pulse, could you be seeing the latency in your calls to whatever you have gating the time count for your signal?  Measuring a pulsed signal in software without a realtime operating system can easily have issues.  It can be done, but is subject to a number of variables.  Hardware based solutions are often easier to implement.

[Jim_81]

The time between pulses is consistantly off for pulses from 1000hz to 1hz so the latiency would be constant per pulse and would cause the time between periods to be to be off by a relivatly constant amount instead of varing along with the frequency.  How is CLOCKS_PER_SEC determined?

[mvr]

clock() is part of the ansi standard.  CLOCKS_PER_SEC is set by the compiler to match the internal timing routines of the compiler.  In the case of CVI they are I believe based on the windows OS.  Without analyzing your code, I can not say why you would be 20% off consistently from 1Hz to 1000Hz. 

Windows is not a real time OS so there will always be issues in SW based timing loops with "when" a function gets called, so getting the timer count is always problematic.  When the event that triggers the timer call occurs you simply have no way of knowing how long it will be before it is serviced.  As far as clock() is described, I don't think there is any guarantee that other processes on the system will not affect the count, but that is compiler dependent.  For the resolution you are looking for I would check out the windows SDK routines

QueryPerformanceFrequency() and QueryPerformanceCounter.  They are far more accurate than clock().