Forum Replies Created
- Posts
AKalman,
The SA series spectrum analyzers are unfortunately not supported on Linux. Only the BB and SM spectrum analyzers are supported.
I apologize for the inconvenience.
Andrew
For the SA series analyzers you cannot query the current temperature or voltage while the device is configured for a measurement. As you noticed, the temperature is not updated as long as the device is active. You can call saAbort to put the device back into an idle mode, at which point you can query the temp/voltage again.
Andrew
Specifically for the zero-span channel power measurement, no, you cannot query that measurement via SCPI.
Yes to your second question, you can load presets remotely via SCPI.
Andrew
Ed,
Unfortunately, this specific measurement would not be possible remotely via programming. While our software does accept SCPI commands (that you could send from Labview or Python) for most functionality, the measurement as configured in the picture above (zero-span channel power) is one of the few that cannot be fully automated.
There are some alternatives,
If you knew exactly what WLAN protocol you were measuring and it was not MIMO, you could use our WLAN measurements to fully capture, demodulate, and report the channel power. All of this is available via SCPI programming. You can determine if your signal would be able to be measured under this measurement mode by browsing our WLAN feature document,
https://signalhound.com/content/tech-briefs/802-11b-a-n-ac-ax-wlan-modulation-analysis-in-spike/.If you were comfortable processing I/Q data, you could use the direct device API to acquire I/Q data, and perform the triggering and channel power measurement yourself. The device APIs are provided in our SDK,
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
Our API is primarily C/C++, but we have several examples on how to call our API from Python or Labview.
https://signalhound.com/software/signal-hound-instrument-drivers-for-labview/If you would like to discuss your specific measurement requirements in more depth, consider reaching out to me directly at aj@signalhound.com.
Andrew
Hi Ed,
Using the zero-span mode in Spike, it is possible to trigger on a WIFI signal, and perform a channel power measurement on that capture. See the attached picture with some relevant highlighting, showing a 20MHz WIFI capture in the 2.4GHz band.
The trigger level, capture length, and channel power bandwidth are all configurable.
Once you have the configuration setup just the way you like, you can store all settings to a preset file that can be quickly loaded the next time you run the application.
Let us know if you have further questions.
Andrew
This thread was resolved via email.
Outcome: Disabling spur reject will raise the noise floor by ~3dB. The artifact in question is likely an internally generated spur that is within the specification of the receiver.
Andrew
Thanks for the update.
I’m glad this resolved the issue.
That’s correct, the FW updater can only be run on Windows. You will need to install the Spike software on the Windows machine to ensure the USB driver is installed. The SM200C must be connected to the PC via USB for the FW update.
Andrew
I have been unsuccessful reproducing the issue with the API. Can you potentially put together a short script that reproduces the problem on your end?
I’m also now considering that you are in fact seeing networked data loss, and that could be tied to your specific hardware configuration and/or software.
While I do see the issue in Spike, I only see it ~1 out of 20 or so reconfigures, and the sweep is not corrupted, which led me to believe it was an erroneous warning.
You also have my email if you wish to communicate via email. It is easier to share pictures and code via email moving forward.
Andrew
The API picks the maximum sweep time that ensures all configuration is met. That includes RBW/VBW/sweeptime. Setting a small sweep time ensures the minimum sweep time is chosen based on RBW/VBW.
I would ignore the uncal warning flag for now if it’s being thrown on the first sweep. I suspect it’s being set erroneously. I was able to reproduce this using your settings. The uncal data flag usually indicates network data loss, I’m going to need to investigate further to determine why it’s returning this warning for this configuration.
Andrew
The allocation error indicates we failed to allocate memory at some point during the configuration. Usually the result of malloc failing. You can see this more often when using the 32-bit version of the API since memory allocation limit is lower.
Is it possible you were passing 200Hz instead of 200kHz as the RBW, or something similar?
Are you using the 32-bit API? If yes, is it possible your own allocated memory was high enough that our API couldn’t stay within the 32-bit limitations?
That being said, its certainly possible this is a bug and a specific combination of settings produces this error code. If you can provide a simple code example that reproduces the problem including information about your OS and what API version you are using, I can try to reproduce it. I was unable to reproduce the issue just based on the information you provided.
Andrew
Yes it is.
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
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
jyaron,
We were never able to close the loop with this customer and determine why he was seeing a discrepancy with their measurements. In general the SA44B has some measurement quirks, but it is possible to measure power levels of OQPSK signals with the SA44B. This customer had very specific measurement requirements, which I believe were contributing to the issue.
In general, the BB60C and SM200 analyzers are better for wideband modulated signals.
Andrew
JV,
Would you mind reaching out to me via email so I can better assist you? My email is aj@signalhound.com. We might need to setup a phone call so I can fully understand what you are trying to do.
I look forward to hearing from you.
Andrew