Check and plot data of an array of touchstone files

[dmvpdx]

Hi,

I'm working on automating a manual board test process. It’s an amplifier board that has 4 types of filters, each of which is associated with an attenuator except the band pass at higher cutoff frequency has 2 attenuators, so I treated at another type of filter in my program. Basically I have a vi that sweeps the attenuator of each filter from 10db to 31db and the output is measured in a VNA. Every time the attenuator gets incremented, the output is updated and my vi will acquire the data from the VNA and save it in a touchstone format. So I’ve figured that part out so far.

Now I need to check to see if the data in the touchstone files that were saved earlier are within the limits for each s-parameter type. By the way, my touchstone files are composed of mag and phase of only s11, s21, s22. So basically I have 110 touchstone files that need to be checked and plotted. What I did in my program is first categorize the touchstones files based on its filter types, and then sort the each category by the attenuator's values (from 10 to 31 because for my application, s11 and s22 should remain the same regardless of the attenuator's values while s21 gets decremented by 1 each time the attenuator gets incremented and therefore the limit for s21 gets decremented as well). After that I read the touchstone files, create an array of 5 elements, each of which are a cluster of 3 elements: filter types, array of frequency and a 2D array (22x3). That is a subVI and the main VI is to set the limits and plot the data.

I figured out the way to do it, but I feel like my program is not really efficient in term of data manipulation because I keep bundle and unbundle them into/out of a cluster and I use so many for loops. My mentor frequently told me my code is not robust and more complex than it's supposed to be, so I'm trying to think of another way to write my program but didn't have any luck so far.  Also, I wasn't able to find a way to identify the filter type and the value of the attenuator if one of the s parameter traces fails. 

Any help would be much appreciated!

Thank you!

MV

[MichaelDB]

Hi dmvpdx,

It's hard to answer a question this broad, but I have a couple points of feedback you might find helpful.  I noticed you use a lot of auto-indexing tunnels in your for loops.  First, I would suggest being careful about using multiple auto-indexed input tunnels on one loop structure.  If the number of elements in each doesn't match, you can sometimes unintentionally introduce bad behavior.  It may be better to make a new array of clusters, and index that.

Second, you could probably combine some loops in your ReadTSFile VI.  If you have an auto-indexed output tunnel feeding into an auto-indexed input tunnel, consider if you can combine those loops.

Third, I would actually use more clusters.  Fewer wires is almost always a good thing for readability, and the performance penalty for clusters is minimal.  It could also help you add functionality later.  For example, you might carry metadata along with your raw values so that you don't have to try to re-associate them later.  This might answer how to identify filter type and attenuator value if a trace fails.  I would try to distill the data down to a single list of clusters (that may contain other clusters) as a way to focus on what is actually important and what information can be discarded or stored in a different way.

If you do choose to use more clusters, it's good practice to make each into a Type Definition.  That way, if you need to make changes, they're reflected in every place the cluster is used automatically.  It's also good practice to bundle and unbundle by name as much as possible.  It makes the code much more readable.

Your code doesn't really have any major structural problems that I can see and it's very readable.  Even not knowing much of anything about s-parameters I can follow what you're doing and why.  Really, readability is going to trump performance every time unless you're really pushing the limits of what your machine can do.

Thanks,

Michael B.

Applications Engineer

National Instruments

[dmvpdx]

Hi Michael,

Thank you so much for the helpful feedback! I was staring at my code for a couple hours the other day and realized some of the loops could be combined together. Also, as you pinpointed in your first suggestion, there is a problem in my code since the number of elements of each filter type aren't the same, and I think I found the way to fix this. 

Thanks again for the feedback!

MV