WCDMA ACLR measurement too slow

[RFguy001]

Hello all,

I use the WCDMA-HSPA+ Analysis Toolkit for doing ACLR measurements. I'm particularly interested in making a fast measurement. So far I couldn't make it run faster than the box-instruments I have available.

Signal:UL FDD, 1 User, 1 DPCCH & 1 DPDCH channel @-5dBm, 2.1 GHz

Task: Measure ACLR at upper and lower adjacent and alternate channel (5 channels in total => ~25MHz span)

With one average the fastest I can get is 6ms. To get a reasonable variance in the results I used 10 averages and the measurement time goes up to 35ms. This seems rather slow to me. I use the niWCDMA Measure ACP Example.vi for this task. I just added some blocks for speed measurements. Inside the niWCDMA RFSA Measure.vi is used for ACLR.

Is there a faster way to do this or improvements I could make? I would really appreciate any help.

Regards

[HeinzG.]

Hello RFguy,

I need some more information, in order to help you:

1. What hardware are you using and how is it connected?

2. What exactly is taking 6ms or 35 ms, the whole vi, one iteration of the for-loop or the RFSA fetch vi?

3. Could you take a screenshot of your settings?

4. Can you post the vi with the changes you have made?

Regards

[RFguy001]

Hello Heinz,

I use the 5663e as VSA and the 5673e as VSG. Both instruments use their own onboard clock. For the test the RF out from the VSG is directly going to the RF in of the VSA.

The measurement time of 6ms includes the execution of the niWCDMA RFSA Measure.vi and the retrieval of the result values with a property node. It takes 6ms to execute these 2 steps once. The loop is just to average the measurement times for a more stable result.

Attached you can find my modified vi and the settings.

Any advice would be very helpful.

Thanks

[Germany_]

Hello RFguy,

I don't have the hardware here to reproduce your problem, but what caught my eye is:

you call the niWCDMA RFSA Measure.vi multiple times. If you take a look into that vi, you initiate and close the aquisition every time you call it. Usually this is what takes the most time. Try to just run the niRFSA Fetch IQ.vi in a loop. For example by manipulating the "Number of Records".

Please let me know if that solves your problem.

Regards

Heinz

[RFguy001]

Hello Heinz,

this is a good point in general, but it doesn't solve the problem here. If I want to capture several data sets the niWCDMA RFSA Measure.vi actually does what you're describing (i.e. by setting the number of averages). My loop that is calling this vi several times is just to repeat the whole measurement several times in order to get a stable speed measurement (by calculating the mean later on). This is only for benchmarking. In real application this look wouldn't exist.

What I figured in the meantime is that doing ACLR with the SMT is actually faster (3 - 4 ms for a single capture compared to 6ms with the WCDMA toolset). I used the example SMT ACP for niRFSA.vi. I saw that there the spectrum mode is used instead of IQ mode. Does this make a difference speedwise?

Any further idea how to get the WCDMA ACLR measurement faster?

Kind regards

[HeinzG.]

Hi RFguy,

sorry I cannot find the SMT ACP for niRFSA.vi.Have you installed any additional Toolkits? Can you post it or tell me where to find it?

Back to the niWCDMA RFSA Measure.vi:

I don't understand why you need to need to initiate the hardware every time you want to aquire data. Do you need to take several measurements with different settings? If not, proceed like this:

1. Initiate the hardware by calling the niRFSA Initiate.vi with the settings you want (i.e. right on startup of you application).

2. Wait until you need to aquire the data.

3. Call the niRFSA Fetch IQ.vi when you need to take a measurement.

4. Call the niRFSA Close.vi when you want to close your whole application.

This will not accelerate the whole process, but the aquisition time. To accelerate the SMT ACP for niRFSA.vi will be similar.

Kind regards

Heinz

[RFguy001]

Hello Heinz,

attached you can find the vi for ACLR measurement with SMT. For the same standard deviation of the ACLR results this vi is faster than the niWCDMA. The SMT vi uses spectrum mode with niRFSA Read Power Spectrum.vi. To my understanding this includes a initiate and fetch. For spectrum mode you can't separate the two steps. However the SMT ACLR is still faster. Any idea why?

I understand your suggestion and in a real application I would proceed as you've described it, but for my speed test I want to know how long it takes to commit settings to hardware and do the measurment. So the loop is not part of the real application. It is just for averaging the speed measurement.

RFGuy

[HeinzG.]

Hi RFguy,

maybe I didn't express myself clearly, sorry for that. What takes the most time is to apply the settings to the hardware (configure). All NI hardware drivers are built the same way (at least all I know) and follow a similar procedure:

1. Create a task & configure the hardware (only needs to be done one time)

2. Get data (can be done in a loop). 

3. Close task (only needs to be done one time)

Lets analyse this for the niWCDMA Measure ACP Example.vi:

1. create a task & configure the hardware: all VIs executed before niRFSA Fetch IQ.vi (inkl. niRFSA Initiate.vi inside the niWCDMA RFSA Measure.vi)

2. get data: is the niRFSA Fetch IQ.vi (inside the niWCDMA RFSA Measure.vi)

3. close task: niRFSA abort.vi, ni RFSA Close.vi, niWCDMA SA Close Session.vi

All other VIs are for data preparation & analysis.

Lets take a look at SMT ACP for ni RFSA.vi:

1. create a task & configure the hardware: steps 1 to 6

2. get data: niRFSA Read Power Spectrum (Cluster).vi

3. close task: niRFSA Close.vi

All other VIs are for data preparation & analysis.

It's easier to get the idea in the 2nd example.

So, if you want to compare how long it takes to retrieve data, you have to compare niRFSA Read Power Spectrum (Cluster).vi and niRFSA Fetch IQ.vi. But I also would consider the time for data preparation & analysis. Therefore you have to modify the niWCDMA RFSA Measure.vi.

I hope this will help you.

Kind regards

[HeinzG.]

I don't know how the "&colon" got there, it should be a simple ":" 

[RFguy001]

Hello Heinz,

thank you for your detailed answer. I totally agree with what you sugessted, but the speed I want to measure includes hardware setting times. The real sceario is like this.

Measure:

1. Harmonics power

2. ACLR for WCDMA signal

3. EVM for WCDMA signal

This is done in loops for different power levels and frequencies of the DUT. So you see that each time I do an ACLR measurement the hardware settings need to be adjusted (ref level or frequency). That's why I include this in the speed measurement loop. In the real application I don't want to do several captures (except for averaging, which is done inside the WCDMA ACLR vi). I use the loop only to average the timing measurement, because a single timing measurement has a large variance.

What I'm not understanding is the fact that with the SMT ACLR vi I get about twice as fast compared to the WCDMA ACLR vi. I compared both devices via the variance of the adjacent channel power reading. To get equal variance and minimal measurement time I got the following settings:

SMT vi: 10KHz RBW, 25.7MHz span, 6 averages

WCDMA vi: 100KHz RBW (fixed), span fixed (unknown), 10 averages

Since identical hardware is used it must be a difference in hardware settings (e.g. sample rate, no of sample), but the WCDMA vi controls most of it automatically.