data aquisition

[svensl]

Hello all,

I am having difficulties extracting data from an agilent 54621a oscilloscope and would appreciate if someone could help me. With the instrument drivers I downloaded from the NI website I can only acquire a maximum of 2000 data points of the signal that fits on the osc. screen. What I would like to do is capture a let's say 100 periods of a signal of which each period has 2000 data points. How can I accomplish this?

Also, is there a way of continuously writing data from the osc to the computer, i.e. in vector form?

Thanks

Ps. I attached my current labview file.

Download File:post-4408-1143459150.vi

[Guest terminator]

Hello all,

I am having difficulties extracting data from an agilent 54621a oscilloscope and would appreciate if someone could help me. With the instrument drivers I downloaded from the NI website I can only acquire a maximum of 2000 data points of the signal that fits on the osc. screen. What I would like to do is capture a let's say 100 periods of a signal of which each period has 2000 data points. How can I accomplish this?

Also, is there a way of continuously writing data from the osc to the computer, i.e. in vector form?

Thanks

Ps. I attached my current labview file.

I have used other Agilent oscilloscopes but not this one. You want to read the manual to figure out what the oscilloscope is capable of doing. Then you can try to modify the vis if necessary.

Now if you really want to AVERAGE 100 scans... that is built into most oscilloscopes these days.

The user and programming manuals are all available on line, and as I recall are pretty complete.

http://cpliterature.product.agilent.com/li...54622-97030.pdf

.

[svensl]

Thanks for the link. I had a look at the manual for the osc. but could not find anything on how to continuously read data. It seems that the data acquisition stops when the osc. internal buffer is full. At least this is according to the manual.

I am sure there is a way of reading data continuously from the oscilloscope. For example, when one wants to capture the signal obtained from a pressure sensor over a long period of time one would need to constantly quire the waveform. I just have no clue how to do that using Labview.

Any ideas?

Cheers,

Sven

[peteski]

Thanks for the link. I had a look at the manual for the osc. but could not find anything on how to continuously read data. It seems that the data acquisition stops when the osc. internal buffer is full. At least this is according to the manual.

I am sure there is a way of reading data continuously from the oscilloscope. For example, when one wants to capture the signal obtained from a pressure sensor over a long period of time one would need to constantly quire the waveform. I just have no clue how to do that using Labview.

Any ideas?

Cheers,

Sven

Sven

When reading data continuously, the devil is firmly planted in the details and waiting to trip you up at any moment! For instance, is your waveform triggered? What frequency is your trigger? What is your sampling rate of your waveform? How many points do you need? Do you need to capture every triggered waveform or will a "representative" sample of triggered waveforms do? And do you plan to do any in-situ analysis of the waveform or just stream them all to disk? Does "reading data continuously" mean for a few seconds, minutes, hours, days, weeks, months, or years?

Once you have done this analysis, you then must consider your scope and the modes it operates in, the buffers it has, and the data throughput of its interfaces (especially the interface you are poised to use!). For instance, 24x7 raw gigahertz measurement, 100% duty cycle, for even just one channel, and expecting to pipe it over a GPIB interface, is losing the battle before beginning!

(I don't mean to imply that the above example is what I think you are doing, its just my way of illustrating an extreme situation.)

BTW, I can't look at your vi, as I'm still sticking with Labview 7.1.1. I'm unwilling to even touch Labview 8 until I see a LabView 8.1 version! (old habit born of getting way too many Labview n.0.n bug bites! )

-Pete Liiva

[svensl]

Thanks for your post Pete. Sorry for not having given all the details. The waveform is a frequency modulated signal at about 17MHz. The oscilloscope is a 60Mhz, 200Msa/s. The modulating signal is a 8khz sine wave (slightly changing during data acquisition). Thus, to get decent information I would like to have 4 periods of the modulating signal = 500us. This is about 8500 periods of the 17MHz signal. For each of the 8500 periods I would like to have as many data points as possible, but a few hundred should suffice. Thus if we say 500 data points per period means 500 * 8500 = 4.25e6 points. All I want is the data points on the disk. I will then process them in Matlab.

Is there a way of telling the oscilloscope to stream the data points continuously to the PC where they

[Guest terminator]

Thanks for your post Pete. Sorry for not having given all the details. The waveform is a frequency modulated signal at about 17MHz. The oscilloscope is a 60Mhz, 200Msa/s. The modulating signal is a 8khz sine wave (slightly changing during data acquisition). Thus, to get decent information I would like to have 4 periods of the modulating signal = 500us. This is about 8500 periods of the 17MHz signal. For each of the 8500 periods I would like to have as many data points as possible, but a few hundred should suffice. Thus if we say 500 data points per period means 500 * 8500 = 4.25e6 points. All I want is the data points on the disk. I will then process them in Matlab.

Is there a way of telling the oscilloscope to stream the data points continuously to the PC where they

[peteski]

Thanks for your post Pete. Sorry for not having given all the details. The waveform is a frequency modulated signal at about 17MHz. The oscilloscope is a 60Mhz, 200Msa/s. The modulating signal is a 8khz sine wave (slightly changing during data acquisition). Thus, to get decent information I would like to have 4 periods of the modulating signal = 500us. This is about 8500 periods of the 17MHz signal. For each of the 8500 periods I would like to have as many data points as possible, but a few hundred should suffice. Thus if we say 500 data points per period means 500 * 8500 = 4.25e6 points. All I want is the data points on the disk. I will then process them in Matlab.

Is there a way of telling the oscilloscope to stream the data points continuously to the PC where they

[svensl]

Again thanks for your valuable feedback.

At the moment I only have access to that particular instrument but might be able to user a better one later. So for the sake of getting the job done assume we

[peteski]

Again thanks for your valuable feedback.

At the moment I only have access to that particular instrument but might be able to user a better one later. So for the sake of getting the job done assume we

[svensl]

Thanks for your thoughts. There are many ways of extracting or rather demodulating the frequency modulated signal. In my case I am interested in the zero crossings of the sine wave (the 17Mhz signal). Each positive going zero crossing corresponds to a total phase change of 2PI. The modulating signal varies the phase of the carrier wave and thus varies the positive zero crossings of the signal. After acquiring the sine wave I would hard-limit it in Matlab to make it a pulse train. Then all that is left is to differentiate the signal and I should obtain the original 8kHz signal after low-pass filtering it.

I will try to make it work with while loops, and/or, using programing.

Thanks for your help.

sven

Ps. I will post any updates.

[peteski]

Thanks for your thoughts. There are many ways of extracting or rather demodulating the frequency modulated signal. In my case I am interested in the zero crossings of the sine wave (the 17Mhz signal). Each positive going zero crossing corresponds to a total phase change of 2PI. The modulating signal varies the phase of the carrier wave and thus varies the positive zero crossings of the signal. After acquiring the sine wave I would hard-limit it in Matlab to make it a pulse train. Then all that is left is to differentiate the signal and I should obtain the original 8kHz signal after low-pass filtering it.

I will try to make it work with while loops, and/or, using programing.

Thanks for your help.

sven

Ps. I will post any updates.

Sven,

I was thinking about it while listening to the radio in the car this morning, that in theory what I was doing in the car seemed to be quite similar to what you seem to be trying to do. It would appear that if you had an FM (Frequency Modulation) receiver that could go down to 17 MHz (my car's FM receiver bottoms out at 88 Mhz ) and a "sound card" capable of continuous recording, you might have something that looks like a solution.

Just a thought...

-Pete Liiva

[svensl]

Yes, my circuit modulates a carrier wave (could be any frequency, but happens to be around 17MHz), with a slowly varying sine wave (could be a voice signal). At the moment I do not transmit the FM signal and use a receiver to receive and demodulate the signal to obtain the original modulating signal. But I will do that in the future. Currently, I want to do the demodulation on my PC as I want to test my modulating circuit to see how much of the original sine wave I can get back.

[peteski]

Yes, my circuit modulates a carrier wave (could be any frequency, but happens to be around 17MHz), with a slowly varying sine wave (could be a voice signal). At the moment I do not transmit the FM signal and use a receiver to receive and demodulate the signal to obtain the original modulating signal. But I will do that in the future. Currently, I want to do the demodulation on my PC as I want to test my modulating circuit to see how much of the original sine wave I can get back.

OK, now that I see more of the pieces, it makes more sense. Well, yes, under the circumstances, you would probably never be able to continuously "stream" data from a 17 MHz signal to allow you to do demodulation in post processing, the throughput of the GPIB interface is just not there. Also, some care has to be taken (and often significant expense) if a continuous stream of such a signal for an indefinite period is sought. Oscilloscopes more often run in modes where they acquire, stop acquiring, then down load, then acquire again, so even if you had an interface that had the clean and clear 170 MBytes / second throughput you would need for transfer of your signal, a well designed double buffered acquisition system would still be needed to cleanly pass the information.

Continuous data streaming of a <20KHz signal is pretty commonplace these days, by comparison!

For demonstration purposes, you will most likely, with your hardware, be restricted to gathering about just under 12 ms of data and then transferring that over the GPIB, then repeat until done. Unless there is some way to export your analysis to the oscilloscope. Some scopes can do some analysis and download the reduced data set, so this might be another thing to look for.

Hope this helps some,

-Pete Liiva

[svensl]

Pete,

I ended up using the data acquisition in a loop which records the FM signal with constant time record. At each new iteration of the loop I move the start time by the time record. Thus, if the modulating sine wave is constant, I should be able to obtain a true representation of the FM signal, even if the osc. stops during streaming the internal buffer data to the PC. However, what I noticed is that after some iterations of the loop, the waveform starts "jittering" around. For example, it does not have an exact zero crossing anymore as it jumps up and down a bit. Once I stop the program and auto-setup everything, the waveform is stable again. Do you know what this might be caused by? I guess it must be due to the fact that with each iteration of the loop I move the start time by N*record_time, where N is the current loop iteration. But I don't know what exactly is causing this. Any ideas?

Cheers,

Sven

[peteski]

Pete,

I ended up using the data acquisition in a loop which records the FM signal with constant time record. At each new iteration of the loop I move the start time by the time record. Thus, if the modulating sine wave is constant, I should be able to obtain a true representation of the FM signal, even if the osc. stops during streaming the internal buffer data to the PC. However, what I noticed is that after some iterations of the loop, the waveform starts "jittering" around. For example, it does not have an exact zero crossing anymore as it jumps up and down a bit. Once I stop the program and auto-setup everything, the waveform is stable again. Do you know what this might be caused by? I guess it must be due to the fact that with each iteration of the loop I move the start time by N*record_time, where N is the current loop iteration. But I don't know what exactly is causing this. Any ideas?

Cheers,

Sven

Sven,

Hmm, from the text of your message, I'm having a hard time "visualizing" exactly what you are doing and seeing. Could you post some images of what the data looks like? Are you trying to gather a record whose length is exactly the size of a single period of your modulating signal? And how do you trigger your waveform acquisition? By "jittering" around, I assume you mean in the time domain, what have you done to try to remain synchronous? You might be seeing subtle differences in the timebase drift between your signal and your measurement devices.

-Pete Liiva

[svensl]

The record time is not exactly the size of a period. It's more like 12.xxx. But I made sure when adding for example two record windows, that there is not discontinuity in the waveform. The trigger of the oscilloscope is just an edge trigger, at dc since the sine wave is centred around dc.

Can you please clarify what you mean by "trying to remain synchronous".

As for the funny behaviour of the waveform: I have a condenser microphone instead of a capacitor in the LC oscillator. Essentially, when excited with sound the capacitances changes, and I obtain a FM signal. Since the change in capacitance is small, I would not expect to see any change on the oscilloscope when exciting the microphone with a sine wave (The deviation in frequency of the FM signal around the carrier might only be 50kHz). And in fact I don

[peteski]

Can you please clarify what you mean by "trying to remain synchronous".

Since you are triggering off of the zero crossing, I think that addresses my concern for remaining synchronous, at least for now. I was not sure of your trigger settings previous to now, and also unsure of your use of the term "jittery" (see below). Around here, what I see in your plot we tend to call "noisy".

However, after a minute into the acquisition, the FM signal seems to become very sensitive to sound. And even if I just whisper the sine wave will become jittery as seen in the attached picture.

If you have behavior which changes on the order of a minute, and all your characteristic frequencies are several orders of magnitude faster, it sounds to me like you are building up some charge somewhere or some bias is developing that is manifesting itself in your data. I'm much more accustomed to jitter be referred to as the temporal uncertainty in the timing of a signal, I *think* what you are seeing is some build-up of high frequency noise on top of your signal.

Is the picture you attached supposed to be the 17 MHz sine wave? Are the units on the bottom number of samples? What is your sample rate? And finally, is this a single waveform, as opposed to being several waveforms superimposed?

If this is a single waveform, and it is supposed to be 17 MHz, you obviously have some much higher frequency noise leaking into your system from somewhere.

Could you post what the waveform looks like when it is not, as you say, "jittery"?

-Pete Liiva

[svensl]

Pete,

Thanks for the response. Since I was taking 2000s point for a record time length of 1e-6 (which corresponds to about 17 periods of the 17MHz signal), my sampling rate would be 2000/1e-6=2GHz. The picture is indeed the FM signal (17MHz), and the x-axis is just the samples. The wave displayed is not superimposed. Below, is the waveform at the beginning of the acquisition.

Regards,

Sven

[peteski]

Pete,

Thanks for the response. Since I was taking 2000s point for a record time length of 1e-6 (which corresponds to about 17 periods of the 17MHz signal), my sampling rate would be 2000/1e-6=2GHz. The picture is indeed the FM signal (17MHz), and the x-axis is just the samples. The wave displayed is not superimposed. Below, is the waveform at the beginning of the acquisition.

Regards,

Sven

Sven,

If you are sampling at 2 GHz, you must have "acquired" a scope other then the agilent 54621a you were using previously - what I see in specifications on that scope seems to indicate that it tops out at 200 MSamples/second.

From all that you have written, I think your problem is strictly a "signal conditioning" problem. Somehow, high frequency noise is leaking into your 17 MHz signal and slowly increasing in amplitude with time. The noise appears to be >>17 MHz, so it is not acoustic in nature, it seems as if some how the acoustic input to the microphone were modulating an amplifier that was amplifying some ambient high frequency noise source and leaking it into your 17 MHz signal directly.

It might be worthwhile doing an FFT on a particularly noisy example of your waveform. If there is a large peak somewhere >>17 MHz, then either some digital filtering of the data, bandwidth limiting at the scope, or analog filtering at the circuit may help. However, the fact that it starts out fine and degrades in a matter of a minute or so bothers me, and I would strongly suggest seeking out an electrical engineer familiar with these kind of signal concerns to look over your circuit. I'm afraid I would not be able to help you in that concern, my background is originally mechanical engineering and I have had a 15 year career in testing and measurement, but I have virtually no experience in circuit design.

Hope this helps,

-Pete Liiva