implementing logarithmic sampling

[tbob]

What you are suggesting to do with the for loop is possible. However, I like Sheldon's idea of sampling at a constant rate and then saving every value for the first 100 values, then every other value for the next 100 values, and so on. This gives a uniform sample rate and an exact time reference for each piece of data. My solution to change sample rates would produce a sort of time space everytime the sample rate is changed. You would have to stop sampling, change the rate, start sampling again. The outputs concatenated together would have points where the time between one sampled data and the next is not consistant. This may not matter in your application. If it doesn't, feel free to use the for loop method.

[Kevin_Price]

newtoni,

You've got an interesting app which is generating quite a bit of interest! I think I have an idea for you that ought to work out, but requires 2 counters (generally available on any of NI's multifunction boards). I'd suggest using DAQmx also. Anyway, here's an overview:

1. Configure your Analog Input task to use one of the counter outputs (let's say #0) as its sampling clock and start it.

2. Configure a Counter Input task on the other counter (let's say #1) that measures periods of the sampling clock and start it. It should be set up with the same buffer size/type as the Analog Input task since it uses the same sampling clock.

3. Configure Counter #0 to generate a continuous pulse train at your highest desired sampling frequency. Start it, then enter your main loop. Note: it is possible to change the frequency of
this pulse train repeatedly without ever stopping it.

4. Request the 1st # of samples from both the Analog and Counter tasks. Once you've retrieved them successfully, change the frequency of Counter #0 to your next sampling rate.

5. Loop back on step 4, each time adjusting the # of samples you request and the next sampling rate until the test is done.

6. After leaving the loop, perform a cumulative sum on the periods you measured to get a hardware-accurate elapsed time to associate with the analog samples.

Note 1: It'll probably take some msec to retrieve 10000 samples and change the counter frequency. So when you next ask for 1000, the first few dozen or so will have been sampled at 10 kHz while the rest were at 1 kHz. However, you'll be able to know how many and which ones because of the period measurement you're doing with Counter #1. In fact, this issue is the reason for Counter #1.

Note 2: For your period measurement, there's a choice of a 100 kHz or a 20 MHz timebase. You'll probably need to use the 100 kHz. If you're using an E-series MIO card, you've got 24-bit counters that'll roll over in less than a second at 20 MHz. So you'd get wrong measurements for any interval longer than that.

Note 3: Yes, you should be able to build it into a standalone executable or dll.

-Kevin P.

[rpursley8]

Attached is a program that might work for you. It acquires blocks of data at logarithmically spaced clock frequencies. I use counter0 to generate the clock. I set up the analog input to use the ctr0InternalOutput as my clock source.

Since the output of the DAQmx Read bases its output on the rate that is initialized at, you can't used the t0 and dt results that come from the DAQmx Read so you have to supply your own and substitute. The output is stored in blocks, each with its own t0 and dt so I then convert it to X-Y data.

Hopefully you can use this as long as your DAQmx Reads take longer than 1 or 2 ms. Let me know if it works out for you.

[newtoni]

dear Mr.Pursley,

thank you for the vi!. i shall try it out and let you know how it works out.