AnsweredAssumed Answered

Obtain at least 30 sweeps per second from the PNA for a short period of time (10-15sec)?

Question asked by ConsueloH on Jan 24, 2018
Latest reply on Feb 19, 2018 by ConsueloH

Like • Show 0 Likes0
Comment • 6

We are using an Agilent N5234A PNA-L Microwave Network Analyzer, 43.5 GHz Firmware Version: A.10.49.11

When asking for help back in December, someone from Keysight team sent me the following:

[..]

If you want to use the CALS:DATA? SCPI command to get data out of the PNA, you should review the example program at

http://na.support.keysight.com/pna/help/latest/Programming/GPIB_Example_Programs/Getting_and_Putting_Data_using_GPIB.htm

If you want to use COM commands, then you should review the example program at

http://na.support.keysight.com/pna/help/latest/Programming/COM_Example_Programs/Getting_Trace_Data_from_the_Analyzer.htm

[..]

I have seen both of the links you sent to me.

I am interested in the ‘Getting and Putting Data using SCPI’ example which is a Visual Basic program meant to be run from the analyzer. That program does not do what I need; besides, I use a LAN connection to the analyzer from a laptop running a Python script to read data, but it is useful to see the commands that might help me to implement what we need for our project.

At the moment, I am getting the data programmatically using the following commands:

CALC:PAR:SEL "CH1_S11_1”

FORM:DATA ASC,0

In a loop:

SENS:SWE:MODE SING

CALC:DATA? FDATA

Reading the sweep data from the buffer

It is not efficient at all. It takes so much time to perform several sweeps and to get us data to plot.

We need to obtain the data of at least 30 sweeps per second. That is why I am asking you for a way to call sweeps and put them into different blocks of memory for 10-15secs.

In the forums I found the following:

https://community.keysight.com/thread/3664

Question

From Piscesking, on Mar 24, 2008

[..] Can we get real time, continuous block data (Real/Img. format) using N5230A 300kHz-13.5GHz (A.04.87.01) PNA-L network analyzer. [especially S21 / S12 measurement data]. [..]

The answer I am interested on:

From Dr_joel on Mar 27, 2008 10:53 PM, on “Step 2:”, he mentions: “send the comand to take a group of sweeps” (SIC)

My comments

Can I have access to a group of sweeps? How?

Question

Again, from Piscesking, on Apr 2, 2008 10:19 AM

[..]

Hi,

Basically what i want to do is,

Read complex data (Re/Im) component for each point.
Save the data into memory.
Once again trigger the sweep and follow step1 and step2.
Repeat the above steps a number of times until I use the maximum of memory.
Transfer the whole bunch of data from memory to hard drive.

[..]

My comments

That is what we need to do. We can get several sweeps, but it takes ages to get us the amount of data we need.

I wonder if you can tell me of a command or a series of commands that can improve my algorithm.

There is this other answer that I am interested in:

From daras, on Apr 2^nd, 2008 12:13 PM

[..]

there is however a workaround that might do what you want. Let's assume that the trace you want to measure is S11. Let's also assume that you want to repeat steps 1-3 ten times. Your program will have to create 10 S11 traces in the channel (when you add duplicate traces in a channel, the data acquisition time does not change :D ). Now your program will loop 10 times and each time it will send a trigger to sweep the channel. After each trigger is complete, you will perform a data->memory operation on one of the traces. So by the time the loop is finished each trace's memory trace will have the data from one of the sweeps. Now if you go through all the traces and transfer the memory trace data, you will have the total data collected during the 10 different sweeps.

The total number of times that you can repeat this process is limited by the total number of traces that you can create in the PNA. With the version of firmware that you are running, that limit is 128. With our latest firmware ( A.07.50.28 ), that limit is 8000 (we have increased the total number of windows to 1000 and you can put 8 traces per window). If you plan on doing this, I would suggest turning off the PNA display (COM -> Application.Visible = false or SCPI-> "DISP:VIS off").

[..]

My comments:

How can I put 8 traces in a window and collect those?

Do you know a command or a series of commands that I can use to obtain at least 30 traces per second from the VNA in a short period of time?

Any help is very much appreciated.

No one else has this question

Outcomes

daras

Jan 24, 2018 12:34 PM

Your best bet is the approach I laid out with memory traces. If you do group trigger, there is no way to retain the data from the individual sweeps in the group. so this means you have to send a SINGLE command for each sweep and you have to have enough copies of the trace, so that you can put the result of each sweep into a different memory trace. so for example if you want to do 30 sweeps for an S11, you'll have to have 30 S11 traces and after each sweep iteration n, you have to put data into memory for trace n. when you have completed all 30 sweeps, with your channel in hold, you can then loop through, select each trace and do a "CALC:DATA? SMEM" and transfer the data. the data from trace n memory buffer represents the S11 for sweep number n. I am attaching a VEE program that sets up this example, but if you can't read VEE programs, I am also attaching a SCPI log of all the commands my program is sending to the analyzer. in my example, the actual sweep time of the channel is about 36 microseconds and on my new N5242B PNA-X and new N5232B PNA-L with the latest CPU, I can do the 30 sweeps in a little over 2 seconds and transfer all the data in about 1.3 seconds. however on my older N5247A PNA-X with the older CPU, the same exact set of measurements with the same 36 microsecond sweep time takes about 8.5 seconds to sweep and about 10.5 seconds to transfer the same amount of data. so basically the bottleneck is the Windows OS overhead to process all the SCPI commands. the new B model PNAs have an intel Celeron 2.2 GHz dual core CPU (4.8 windows experience index) and the A model PNA-X has an intel i7 2 GHz quad core (3.3 Windows Experience Index).

So the moral of the story is that even with a very fast channel sweep time of 36 microseconds (this is the physical data acquisition time), the overhead required for processing all the commands you need to save the data from each sweep, is going to make it very unlikely that you can sweep and transfer data from 30 sweeps in 1 second or less.

Attachments

Fast30Sweeps.txt.zip867 bytes
Fast30Sweeps.vee.zip4.5 KB

1 person found this helpful

Actions

ConsueloH @ daras on Jan 29, 2018 2:48 AM

Hello daras,

Just to let you know that we are working out your first recommendation. For testing purposes, we are only using the first window with 20 traces. We also changed the frequency: 1 to 14GHz.

We are getting the SCPI error 106: “Requested measurement not found”. We must have made a mistake somewhere in the code. We will continue working on it and update this post once we have any progress.

...

s.sendall('SYST:FPR\n'.encode('utf8'))
s.sendall('DISP:WIND1 ON\n'.encode('utf8'))
s.sendall('DISP:WIND2 ON\n'.encode('utf8'))

for theTrace in range(1, 21):
trace = str(theTrace)
calcCommand = 'CALC1:PAR:DEF:EXT "meas' + trace + '", "S11"\n'
dispCommand = 'DISP:WIND1:TRAC' + trace + ':FEED "meas' + trace + '"\n'
s.sendall(calcCommand.encode('utf8'))
s.sendall(dispCommand.encode('utf8'))

s.sendall('SENS1:SWE:MODE HOLD\n'.encode('utf8'))
s.sendall('SENS1:FREQ:STAR 1E9\n'.encode('utf8'))
s.sendall('SENS1:FREQ:STOP 14E9\n'.encode('utf8'))
s.sendall('SENS1:SWE:POIN 5\n'.encode('utf8'))
s.sendall('*OPC?\n'.encode('utf8'))
s.sendall('DISP:ENABLE OFF\n'.encode('utf8'))

for theTrace in range(1, 21):
trace = str(theTrace)
s.sendall('SENS1:SWE:MODE SING\n'.encode('utf8'))
s.sendall('*OPC?\n'.encode('utf8'))
calcCommand = 'CALC1:PAR:MNUM ' + trace + '\n'

s.sendall(calcCommand.encode('utf8'))
s.sendall('CALC1:MATH:MEM\n'.encode('utf8'))

dispCommand = 'DISP:WIND1:TRAC' + trace + ':MEM:STAT ON\n'

s.sendall(dispCommand.encode('utf8'))

''' Jan 29, 2018. I missed the following line: '''

s.sendall('FORM REAL, 32\n'.encode('utf8'))

for theTrace in range(1, 21):
trace = str(theTrace)
calcCommand = 'CALC1:PAR:MNUM ' + trace + '\n'
s.sendall(calcCommand.encode('utf8'))
s.sendall('CALC:DATA? SMEM\n'.encode('utf8'))

s.sendall('DISP:ENABLE ON\n'.encode('utf8'))
s.sendall('SENS1:SWE:TIME?\n'.encode('utf8'))

...

Actions

ConsueloH Jan 25, 2018 1:51 AM

Hi daras,

Many thanks for your thorough answer. I am impressed with the detail you have given us; that itself answers other questions for us as well. Really: thanks.

We have to be fast on the reading, not so on the writing. Getting as many sweeps as we can in between 10-15 secs is the big deal; analysing it afterwards might take us longer, and it is okay.

Before reading your message, a colleague did just what you have described by pushing bottoms on the analyser. We wonder if that would be the lead to follow. With your answer, we have confirmed that we are heading a good direction (and why), and what are our restrains. The files you sent us are very helpful as well for us to go straight to optimise our Python script.

"Interesting that the bottleneck is not the sweep but physically transferring data in the analyser. I wonder if anyone else will reply with an alternative?", my colleague said.

For now, though, we will concentrate on following this method for our next Trial.

We will try and publish here how many sweeps per second we achieved.

Thank you, Daras.

Actions

daras

@ ConsueloH on Jan 25, 2018 10:35 AM

The only other alternative I can think of is instead of having 30 traces and their memory buffers in one channel, have 30 different identical channels (you can use the copy channel interface to conveniently replicate multiple copies of a channel once you have the first one setup the way you want). the trick here is to setup the original channel in continuous sweep and manual trigger source (the default trigger source is Internal). the default trigger scope is global, so when you have multiple channels all in continuous sweep and manual trigger source, they will all be on hold waiting on a trigger. if you then send one manual trigger, each of the channels will sweep once in the order of the channel number and if you OPC or serial poll that manual trigger command, it will return when all the channels have completed their sweep. this could potentially be faster than my previous example because you only need to send one command to initiate the 30 sweeps and you only need one OPC to know when it is done. if you capture the data using the calc:data? command, then the timing would be the same as the previous example, but another alternative here is to send a MMEM:STOR:DATA command and set it up to store all displayed traces. Since you do the post processing of the data offline anyways, this might yet be the fastest way to do it. If I get a chance in the next few days, I will work on another example to set this up and post it here with some timing data to compare to the memory trace approach.

Also I don't know if you noticed this in the code that I posted, but a key element of making everything go as fast as possible is disabling the display update while you are doing all this. no having to update the display while taking sweeps makes a significant performance improvement.

Actions

Dr_joel

Feb 16, 2018 1:40 PM

Easily done, depending on the sweep rate etc. One key is to turn off the display update.

I can achieve 31 msec sweep and read S2P data (about 32 sweeps per second) on a PNA with 1 GHz span and 201 points, if display update is off. Display update on slows it to 165 msec (about 5 per second).

Here's the commands, I first set the form for data to binary, the find the active measurement, then use calc:par:cat to select the measurement and set it to fast mode. Turn the display enable on (in case it was left off), take a sweep, read the data, time this (165 msec), then turn display enable off, sweep and read again. My speed test code can also do repeated tests, so 30sweeps is less than 1 second. . Not too hard to implement.

FORM REAL,32
Syst:Active:Meas?
Calc:Par:Sel 'CH1_S11_2', FAST
Disp:Enab ON
SENS:SWE:MODE SING;*OPC?
CALC:DATA:SNP:PORTs? "1,2"
Disp:Enab Off
SENS:SWE:MODE SING;*OPC?
CALC:DATA:SNP:PORTs? "1,2"
Disp:Enab On

1 person found this helpful

Actions

ConsueloH @ Dr_joel on Feb 19, 2018 3:36 AM

Many thanks, @Dr_joel.

I am using Python, and can translate those commands into my script almost literally, but the

SENS:SWE:MODE SING;*OPC?

because that is two commands in one line, isn't it?

My SCPI command sequence is pretty much like yours, and I put the sweep in a variable because I need to store that data immediately.

So the sequence I use is:

...

loop

SENS:SWE:MODE SING

CALC:DATA? FDAT

read and store data in a variable (from the buffer to a data structure in Python -numpy / pandas-)

end loop

...

I can do up to 30 of those per second. Not all the data I get is good. I discard those readings that fail the data assemblage I am expecting. Still, I get a good number of readings.

I know, for instance, that if I put a *OPC? inside the loop, half the data I save will be a '+1' string, instead of the 201 points from the sweep, in addition, it slower the readings considerably.

I might have broken a rule by not using the *OPC?, though.

Could you be so kind to tell me what is the consequence of not sending a *OPC? after a SENS:SWE:MODE SING, please?

Kind regards,

Consuelo.

Actions

6 Replies

daras Jan 24, 2018 12:34 PM
Mark Correct
Correct Answer
Your best bet is the approach I laid out with memory traces. If you do group trigger, there is no way to retain the data from the individual sweeps in the group. so this means you have to send a SINGLE command for each sweep and you have to have enough copies of the trace, so that you can put the result of each sweep into a different memory trace. so for example if you want to do 30 sweeps for an S11, you'll have to have 30 S11 traces and after each sweep iteration n, you have to put data into memory for trace n. when you have completed all 30 sweeps, with your channel in hold, you can then loop through, select each trace and do a "CALC:DATA? SMEM" and transfer the data. the data from trace n memory buffer represents the S11 for sweep number n. I am attaching a VEE program that sets up this example, but if you can't read VEE programs, I am also attaching a SCPI log of all the commands my program is sending to the analyzer. in my example, the actual sweep time of the channel is about 36 microseconds and on my new N5242B PNA-X and new N5232B PNA-L with the latest CPU, I can do the 30 sweeps in a little over 2 seconds and transfer all the data in about 1.3 seconds. however on my older N5247A PNA-X with the older CPU, the same exact set of measurements with the same 36 microsecond sweep time takes about 8.5 seconds to sweep and about 10.5 seconds to transfer the same amount of data. so basically the bottleneck is the Windows OS overhead to process all the SCPI commands. the new B model PNAs have an intel Celeron 2.2 GHz dual core CPU (4.8 windows experience index) and the A model PNA-X has an intel i7 2 GHz quad core (3.3 Windows Experience Index).

So the moral of the story is that even with a very fast channel sweep time of 36 microseconds (this is the physical data acquisition time), the overhead required for processing all the commands you need to save the data from each sweep, is going to make it very unlikely that you can sweep and transfer data from 30 sweeps in 1 second or less.
Attachments
- Fast30Sweeps.txt.zip867 bytes
- Fast30Sweeps.vee.zip4.5 KB
1 person found this helpful
Like • Show 1 Like1
Actions
- ConsueloH @ daras on Jan 29, 2018 2:48 AM
  Mark Correct
  Correct Answer
  Hello daras,
  
  Just to let you know that we are working out your first recommendation. For testing purposes, we are only using the first window with 20 traces. We also changed the frequency: 1 to 14GHz.
  We are getting the SCPI error 106: “Requested measurement not found”. We must have made a mistake somewhere in the code. We will continue working on it and update this post once we have any progress.
  ...
  s.sendall('SYST:FPR\n'.encode('utf8'))
  s.sendall('DISP:WIND1 ON\n'.encode('utf8'))
  s.sendall('DISP:WIND2 ON\n'.encode('utf8'))
  
  for theTrace in range(1, 21):
  trace = str(theTrace)
  calcCommand = 'CALC1:PAR:DEF:EXT "meas' + trace + '", "S11"\n'
  dispCommand = 'DISP:WIND1:TRAC' + trace + ':FEED "meas' + trace + '"\n'
  s.sendall(calcCommand.encode('utf8'))
  s.sendall(dispCommand.encode('utf8'))
  
  s.sendall('SENS1:SWE:MODE HOLD\n'.encode('utf8'))
  s.sendall('SENS1:FREQ:STAR 1E9\n'.encode('utf8'))
  s.sendall('SENS1:FREQ:STOP 14E9\n'.encode('utf8'))
  s.sendall('SENS1:SWE:POIN 5\n'.encode('utf8'))
  s.sendall('*OPC?\n'.encode('utf8'))
  s.sendall('DISP:ENABLE OFF\n'.encode('utf8'))
  
  for theTrace in range(1, 21):
  trace = str(theTrace)
  s.sendall('SENS1:SWE:MODE SING\n'.encode('utf8'))
  s.sendall('*OPC?\n'.encode('utf8'))
  calcCommand = 'CALC1:PAR:MNUM ' + trace + '\n'
  s.sendall(calcCommand.encode('utf8'))
  s.sendall('CALC1:MATH:MEM\n'.encode('utf8'))
  dispCommand = 'DISP:WIND1:TRAC' + trace + ':MEM:STAT ON\n'
  s.sendall(dispCommand.encode('utf8'))
  
  ''' Jan 29, 2018. I missed the following line: '''
  s.sendall('FORM REAL, 32\n'.encode('utf8'))
  
  for theTrace in range(1, 21):
  trace = str(theTrace)
  calcCommand = 'CALC1:PAR:MNUM ' + trace + '\n'
  s.sendall(calcCommand.encode('utf8'))
  s.sendall('CALC:DATA? SMEM\n'.encode('utf8'))
  
  s.sendall('DISP:ENABLE ON\n'.encode('utf8'))
  s.sendall('SENS1:SWE:TIME?\n'.encode('utf8'))
  ...
  Like • Show 0 Likes0
  Actions
ConsueloH Jan 25, 2018 1:51 AM
Mark Correct
Correct Answer
Hi daras,

Many thanks for your thorough answer. I am impressed with the detail you have given us; that itself answers other questions for us as well. Really: thanks.

We have to be fast on the reading, not so on the writing. Getting as many sweeps as we can in between 10-15 secs is the big deal; analysing it afterwards might take us longer, and it is okay.

Before reading your message, a colleague did just what you have described by pushing bottoms on the analyser. We wonder if that would be the lead to follow. With your answer, we have confirmed that we are heading a good direction (and why), and what are our restrains. The files you sent us are very helpful as well for us to go straight to optimise our Python script.

"Interesting that the bottleneck is not the sweep but physically transferring data in the analyser. I wonder if anyone else will reply with an alternative?", my colleague said.

For now, though, we will concentrate on following this method for our next Trial.

We will try and publish here how many sweeps per second we achieved.

Thank you, Daras.
Like • Show 0 Likes0
Actions
- daras @ ConsueloH on Jan 25, 2018 10:35 AM
  Mark Correct
  Correct Answer
  The only other alternative I can think of is instead of having 30 traces and their memory buffers in one channel, have 30 different identical channels (you can use the copy channel interface to conveniently replicate multiple copies of a channel once you have the first one setup the way you want). the trick here is to setup the original channel in continuous sweep and manual trigger source (the default trigger source is Internal). the default trigger scope is global, so when you have multiple channels all in continuous sweep and manual trigger source, they will all be on hold waiting on a trigger. if you then send one manual trigger, each of the channels will sweep once in the order of the channel number and if you OPC or serial poll that manual trigger command, it will return when all the channels have completed their sweep. this could potentially be faster than my previous example because you only need to send one command to initiate the 30 sweeps and you only need one OPC to know when it is done. if you capture the data using the calc:data? command, then the timing would be the same as the previous example, but another alternative here is to send a MMEM:STOR:DATA command and set it up to store all displayed traces. Since you do the post processing of the data offline anyways, this might yet be the fastest way to do it. If I get a chance in the next few days, I will work on another example to set this up and post it here with some timing data to compare to the memory trace approach.
  
  Also I don't know if you noticed this in the code that I posted, but a key element of making everything go as fast as possible is disabling the display update while you are doing all this. no having to update the display while taking sweeps makes a significant performance improvement.
  Like • Show 0 Likes0
  Actions
Dr_joel Feb 16, 2018 1:40 PM
Mark Correct
Correct Answer
Easily done, depending on the sweep rate etc. One key is to turn off the display update.

I can achieve 31 msec sweep and read S2P data (about 32 sweeps per second) on a PNA with 1 GHz span and 201 points, if display update is off. Display update on slows it to 165 msec (about 5 per second).

Here's the commands, I first set the form for data to binary, the find the active measurement, then use calc:par:cat to select the measurement and set it to fast mode. Turn the display enable on (in case it was left off), take a sweep, read the data, time this (165 msec), then turn display enable off, sweep and read again. My speed test code can also do repeated tests, so 30sweeps is less than 1 second. . Not too hard to implement.

FORM REAL,32
Syst:Active:Meas?
Calc:Par:Sel 'CH1_S11_2', FAST
Disp:Enab ON
SENS:SWE:MODE SING;*OPC?
CALC:DATA:SNP:PORTs? "1,2"
Disp:Enab Off
SENS:SWE:MODE SING;*OPC?
CALC:DATA:SNP:PORTs? "1,2"
Disp:Enab On
1 person found this helpful
Like • Show 1 Like1
Actions
- ConsueloH @ Dr_joel on Feb 19, 2018 3:36 AM
  Mark Correct
  Correct Answer
  Many thanks, @Dr_joel.
  
  I am using Python, and can translate those commands into my script almost literally, but the
  SENS:SWE:MODE SING;*OPC?
  because that is two commands in one line, isn't it?
  
  My SCPI command sequence is pretty much like yours, and I put the sweep in a variable because I need to store that data immediately.
  
  So the sequence I use is:
  ...
  
  loop
  SENS:SWE:MODE SING
  CALC:DATA? FDAT
  read and store data in a variable (from the buffer to a data structure in Python -numpy / pandas-)
  end loop
  ...
  I can do up to 30 of those per second. Not all the data I get is good. I discard those readings that fail the data assemblage I am expecting. Still, I get a good number of readings.
  
  I know, for instance, that if I put a *OPC? inside the loop, half the data I save will be a '+1' string, instead of the 201 points from the sweep, in addition, it slower the readings considerably.
  
  I might have broken a rule by not using the *OPC?, though.
  
  Could you be so kind to tell me what is the consequence of not sending a *OPC? after a SENS:SWE:MODE SING, please?
  
  Kind regards,
  Consuelo.
  Like • Show 0 Likes0
  Actions

Obtain at least 30 sweeps per second from the PNA for a short period of time (10-15sec)?

Outcomes

Attachments

Related Content

Recommended Content