interface help for tds 3012b scope

[myra]

Hi!

Thanks for your reply.  I definitely use context help a lot - it's a lifesaver! 

So the time per record does determine the sampling rate - what I mean is, I wasn't sure if the time per record that you choose determines how often the data is acquired, or if it just determines how much of the waveform that you see on the graph (basically, the horizontal scale).  I'm concerned about this because when I set the time per record to roughly the period of my wave, if I vary the amplitude smoothly, the response that I see on my graph is not smooth - it's pretty choppy.  I'm assuming that means that I need to sample more often, but then the horizontal scale of my graph is off (i.e., it's much smaller than a wavelength).  Can I separately control the horizontal scale for my graph?  I mean, sample at one rate but observe at a lower one?  Or could I just decrease the record length substantially?

I think most of my problems are stemming from the fact that there's not really any documentation that goes with the driver (at least, I haven't seen any 🙂 );  for instance, there is a configurate continuous acquisition vi, but it is never used in the examples.  I don't know where it would go in my code, and what, if anything, it would need to replace.  When I've tried to just stick it in (before my while loop) I get all kinds of errors!  Of course I've tried to use the context help, but they don't give that much detail on each vi - I need something that tells me exactly which configuration vis I need to use for different types of acquisition.  Another vi I have some trouble with is that for the FFT (my oscilloscope calculates it - I'm just trying to retrieve it, not calculate it myself)...  there is a vi to configure the FFT math channel, but after that I'm not sure how to read it.  Can I just use the same fetch vi as I do for channels 1 and 2, configured for that channel?

Does anyone here have any experience with this particular driver, or are all oscilloscope drivers basically the same?

Thanks!  Myra

[Albert.Geven]

Hi Myra

The problem you have with the choppy look of the display is indeed a timing problem, but one that is difficult to solve.
The problem exists because of the am ount of data that you need to transfer to the pc via an older bus standard.
During this transfer the scope is not measuring but only transferring data.
You get a feeling for this when you measure the time of each transfer (read the system clock (tick count ms)) before and after you read the data.
(you can be sure that tick count reads the time at the correct moment whe you put it in a sequence frame that in a next frame contains the timed software and in the third frame the second tick count.
Subtract the first from the last tick count and you see the number of ms of the transfer.
The more datapoints you read the slower the system gets.

A possible solution is an NI scope card that has a much faster bus speed.

[myra]

Thank you!  I was worried about that - I'll set up my program to read the clock after I finish this note.  I was just wondering - when you mentioned the 'old bus' system, would that be GPIB only?  I'm using an ethernet connection, so I thought that should be faster, right? 

Do you happen to know how much the NI scope board costs, roughly?  I think we would only need two inputs.  That option, at least, wouldn't require so much programming on my end, correct?

Myra

[Albert.Geven]

You can use the daq advisor on NI.COM to find out how much this scope card costs in your country.

Ethernet can be fast but in this case I think that the scope is slowing the datatransfer.