signal generation using the data from matlab script node

[pjj]

Hello Raajit L:

In streaming mode, I'm still not sure what size of memory to allocate to the waveform. I tried several amount of memory, each time I get an error like "memory full" even for a very large memory. Is there any relationship between the memory needed and the complex data symbols used for generating waveform? 

I have one more question about the block of "niFgen Create Waveform (poly)".

In the help,  it's said that that "signal generator must not be in the Generating state when you call any instance of this polymorphic VI".  But I find that the waveform handle (output) of this VI is increasing with the loop, for example: 10001,10002...and so on. Does it mean the dynamic waveform is being generated according to the varying data from matlab srcipt, or just being created in the memory without being generated ?  If the former case, then it's the right waveform for my application and I should look into other potential problem.

Attached is the vi for reference.

Thanks a lot for your kind help:-)

Best Regards! 

[Raajit_Lall]

Hi,

Thank you for the VI, it is easier to see what you are trying to achieve now.  The waveform handle does change according to every new waveform that you are generating.  Could you tell me what kind of board you are using as your function generator? Each board has onboard memory and as long as there is enough memory onboard you should not be getting a memory full error.  The PXI 5421 for example comes with 8MB, 32MB or 512 MB options.  Could you give me the error code for the memory full error that you are getting.  It might be related to LabVIEW memory and not the FGEN memory. 

The Create Waveform VI should be called before the FGEN is in writing state because the waveforms are written to the memory.  You could also use the niFgen Set Waveform Next Write Position VI to write the waveform to a particular position on the onboard memory.  Although, as you can see in the streaming VI that I posted before you could also wait for the memory to be empty and then write the next waveform.  This depends on how you want to utilize the memory.

Regards,

[pjj]

Hello Raajit L:

Thanks very much. The board I'm using is 5441 and the onboard memory is 256M.

After modification like you mentioned, the error is 1074118519 occurred at niFgen Initiate Generation:

Drive Status:(Hex OxBFFA4089)

The data being written to the streaming waveform cannot keep up with the output. Decrease the sample rate or write data to the streaming waveform more frequently.

(I allocate the memory size to the waveform is 67108864, I guess it's 64M)

Enclosed is the modified VI for your reference.

Best Regards!

Jingjing

[pjj]

Hello Raajit L:

I get from "niFgen Query Arb Waveform Capabilities.vi" that the maximum waveform size is 67108864, so I allocate 64M to the waveform. Am I right?

I guess the error I just mentioned in the last thread will be memory full, if the case structure of query for the space available is deleted.

Best Regards!

Jingjing

[Ryan_V[DE]]

Hello Jingjing,

After reading this thread, I have a question about your overall application. How is it that you are trying to output your data? Are you looking for real-time performance (e.g. you create IQ data in Matlab at least as fast as you generate (output) it)? Or are you interested in aperiodically generating a waveform (you want your generator to output a "packet," then cease generating until you download a new "packet")? Or do you want some kind of repetitive generation (you repeatedly output one waveform until you create a new one in matlab, then when the initial waveform completes, you begin repeatedly generating the new one). Let's call these options A, B, and C:

A: real-time, continuous (what we would call streaming) output
B: aperiodic waveform generation
C: repetitive waveform generation, with aperiodic updates

Under which of these would you classify your application? A few comments for each scenario:

A: This will require high performance to calculate data in real time and potentially large buffers requiring lots of memory. What is your IQ rate? Are you sure that your matlab computation can run fast enough on your machine?
B: This should be very simple, requiring only that you wait for generation to complete, clear the waveform, then begin generating again.
C: This can be done in Arbitrary Sequence mode, which basically controls how multiple waveforms can be generated in succesion . More information on this technique can be found here.

Please let us know your desired behavior, and that will help us to get you going in the right direction. I'm also intrigued by this application. Any details you have on the application as a whole would be very much appreciated. Thanks!

Regards,


Message Edited by Ryan V[DE] on 01-21-2008 01:48 PM

[Ryan_V[DE]]

Hi Jingjing,

One more thing... I noticed you were sharing the 10 MHz reference of the two upconverters (and thus AWGs). I wanted to point out that though you will be phase locked and your clocks will not drift over time, the phase noise will be uncorrelated.

Ryan

[pjj]

Hello Ryan

Thank you for your kind support:-)
I cannot explicitly attribute it to one of the three scenarios. The overall application seems like a

mixture of A and B.

Just like you've mentioned, the matlab computation cannot run fast enough. One reason of time

consuming is matrixes manipulation in the script, and another important reason is that the input of

matlab depends on higher level(Tcp in my application). Thus matlab script computes in a loop of nearly

1 second according to the data from Tcp link. (New data from Tcp will trigger a new cycle of the

loop.)

It's expected that before new data arrives from output of matlab, the waveform continously keeps

generating using the current data. As soon as new data is created, the waveform should be update to

overwrite the original one.

It seems more like the option B. But I've already tested: abort generation-> clear memory-> create waveform. The result is no explicit waveform can be seen from spectrum analyser, since the duration of each waveform is small(about 1second). At the receiver, only noise is captured.

If the application can be attributed to option B, then how can I solve the above problem due to abort generation and clear memory?

Thanks^_^

Best Regards!
Jingjing

[Ryan_V[DE]]

Hello Jingjing,

Are you sure this would not fall under option C? It sounds like it to me. In this scenario, you would always have something on the output of the generator. You would also generate contiguous waveforms, updating with a new waveform only after the prior waveform has been completely generated. The basic method is that you set up a sequence of two waveforms, with a burst software trigger to advance to the next waveform. You first download waveform #1, then begin generating. When you have new data, you then download waveform # 2, and send a software trigger. Upon completion of the current iteration of waveform #1, the AWG will begin generating waveform #2. Again, when you have new data, you overwrite waveform #1 and send a software trigger, etc., etc. Effectively, you are "hopping" back and forth between the two waveforms, guaranteeing continuous output. Does that sound like it would work? Thanks!

[pjj]

Hello Ryan:

Thanks for your suggestion:-) I've gained your point. But one question is that for "niFgen Create Advanced Arb Sequence.vi",  I don't know to fill "loop counts array ". But the duration of each waveform is not configurable since it depends on the time duration between the data arrival from higher application(Tcp). Can this problem be solved?

Best Regards!

Jingjing 

[pjj]

Hello Ryan:

One more question: I got from the help that "The signal generator must not be in the Generating state when you call this VI".

So I guess when downloading a new waveform, this vi cannot work and change the waveform on the fly.

Best Regards!

Jingjing