Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Duty Cycle - Calculations

Hello,

I have spent the most of the day trying to figure out why my duty cycle calculations were not going any faster then .1 sec.

I am aquire data from 13 accelerometers at a frequency of 20000 Hz. When I put this through the Express VI to calculate the duty cycle, the time step always goes to .1 sec.

My question really is it possible to make this faster? The duty cycle of my accels are around 10ms.

I tried to dive into the express vi's front panels, but that didn't seem to have any good answer.

Thanks,
Royce
0 Kudos
Message 1 of 4
(2,779 Views)
Royce,

The formula for the computation of the duty cycle is: Duty cycle = (Pulse duration/Period). So what you are seeing as being 0.1 is actually the fractional component that is considered to be high in regards to the period.

A great test for this is simply feed in a TTL pulse to the Timing and Transition Measurements Express VI. If you vary the Pulse Width, then you will see the resultant answer vary between 0.1 and 0.9 depending upon your pulse width.
0 Kudos
Message 2 of 4
(2,763 Views)
I think that you mis-understood what I was getting at. I get excellent readings in terms of the duty cycle output. The accels duty cycle ranges from around .25 -> .75 in my case. I even setup a nice little config block to get everything to around .5 to adujust easily to gravity readout for all 13. The problem that I am having is that the duty cycle conversion doesn't seem to read out all values of the input. The duty cycle will readout only 1 sample every .1 secs. That readout I believe should really be less then .01 secs depending on the resistor values that I have set up for my accels etc. What is even more interesting is that with the dynamic data readout, if I were to probe the data. Since I am reading at 20000 Hz, it is telling me that my dt should be .00005 secs. Which was fine for sampling of my input duty cycle wave, but afterwards that dt value should be scaled down to the actual frequncy. Now, if the program was written to take an average of duty cycles over .1 secs to fix the output period to a standard amount instead of having all sorts of strange step sizes since each reading (accel) generally has a different output frequncy the program forces that conversion to .1 sec period then fine or that is just takes a sample of 10, I guess I will have to deal. But, I did have the option to have a lot higher sampling rate for my accels, and if the .vi forces everything to .1 sec period for duty cycle output or if it takes an average of 10 readings and then rounds to the nearest sig digits this should be documented in the .vi for the duty cycle so that it is clear. If I am way off base and I shoudln't be getting a reading resulting from the duty cycle every .1 secs then I guess I am really lost. But, I do understand where the duty cycle readout comes from, that part is simple enough.

Thanks!

Royce
0 Kudos
Message 3 of 4
(2,762 Views)
I think what may be occurring here is that it seems to take 0.1 seconds because that is the amount of data that we are reading. For example, if I sample at 1000 S/s and read 100 samples at a time, then the amount of time between reads is 0.1 seconds.

The Time and Transition Measurements does do as you suspected and takes the average Duty Cycle for the chunk of data that it is given.

Just to make sure that everything works as I thought I made a test VI that shows the amount of execution time for the actual Time and Transition Measurements VI. By profiling the VI (Tools > Advanced > Profile VI...) I found the maximum time for this VI to take about 0.01 s with an average execution time of 0.003 s.

If you think that the documentation is unclear the please make a product suggestion so that others don't have to go thru what you did. Product Suggestion Center
0 Kudos
Message 4 of 4
(2,744 Views)