Question on SM200C frequency sweeping modes

We generally operate our SM200C in frequency sweeping “normal mode” and set a start/stop frequency. We would like to now allow our users the ability to set the rbw and period as well. Looking at the API documentation, I am not 100% sure I understand the best way to present the options to the user (I am most interested in normal and fast mode right now). The documentation states “The sweep speed is primarily set by the user explicitly, except in a few cases.” What are those cases?

Also, it appears that a user can set one of three modes, or set to “fastest sweep speed.” But since sweep time is “not selectable when measuring at the fast sweep rate,” does that mean that the API ignores it if a user tries to set it? Or will it drop out of fast mode and go to normal in order to use the value?

Lastly, it looks like the SmSweepSpeed doesn’t even have a slow/narrow option in the sm_api.h document, just auto, normal, and fast. I am guessing that auto is the one that chooses the fastest sweep speed based on the setting chosen?

[Andrew]

Yes, the sweep speed is by default set to auto and will choose the fastest sweep speed based on your configuration. I would leave it in this configuration unless you have explicit need to achieve some probability of intercept offered by the fast sweep speed. If you choose a narrow span, the API will override your selection and perform the “slow”/narrow sweeps regardless. That span cutoff is 5MHz. Slow sweep speed is not selectable otherwise.

If you choose fast sweep speed, VBW must equal RBW and your lower limit on RBW is 30/60kHz depending on window function selected. If your settings meet these restrictions we will automatically choose fast sweep speed when auto is selected.

I hope this clarifies.

Andrew

• This reply was modified 3 years ago by Andrew.

Thank you for the quick response. We were only going to give the user options for start/stop frequency, rbw, and period. Based on that, I think the best thing to do is to follow your recommendation and leave the speed as “auto” and let the user’s parameters drive the speed.

Do you have a recommendation for a safe window type since I am not going to give the user the ability to set it? I see you use flat-top in your example sweep app, but Nuttall in your thz sweep (btw, you spelled Nuttal with only a single ‘t’ in the API). I am leaning towards Nuttal, but I figured I would double check.

This seem like a reasonable set of API calls?

smSetSweepSpeed(this_device, smSweepSpeedAuto);
smSetSweepStartStop(this_device, this_startFrequency, this_stopFrequency);
smSetSweepCoupling(this_device, this_rbw, this_rbw, this_period);
smSetSweepDetector(this_device, smDetectorAverage, smVideoPower);
smSetSweepScale(this_device, smScaleLog);
smSetSweepWindow(this_device, smWindowNutall);
smSetSweepSpurReject(this_device, smFalse);
smSetAttenuator(this_device, -1/*auto*/);
smSetPreselector(this_device, smFalse);
smSetReference(this_device, smReferenceUseExternal);
shStatus = smConfigure(this_device, smModeSweeping);

Thanks again

The flattop window is better for amplitude accuracy but requires about twice as much data acquisition for a sweep with the same RBW. This means the Nuttall window can sometimes result in a faster sweep for specific configurations at the expense of up to ~0.7dB amplitude accuracy. So it depends on what tradeoffs you are willing to make. The rest of your settings are good defaults IMO.

Andrew

OK, I will go with Nuttall for now until someone on our end complains to me about it. Is the Nuttall window the one that caps out with a minimum of 30kHz for RBW (it wasn’t clear to me in the API document)?

Yes it is.

[Author]

Posts