Forum Replies Created
- Posts
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
Jared,
1) As long as the DLL is loaded, if you have opened the device via the saOpenDevice function, you will not be able to open the device again until either, you close the device, or unload the DLL. We have seen some environments like Matlab/Labview keep the DLLs loaded until you restart the environment. One way customers have got around this is by closing all possible device handles before their script starts, this ensures any open devices from a previous run close. If you are interfacing a single device, the handle will always be 0, so you can just call saCloseDevice(0) at the beginning of your script and that should make it available again.
2) The Python libraries may not stay completely up to date with the C ones. You can just add the function to the python interface. I believe we have implemented this function for the BB and/or SM200 APIs, you could check the python interfaces for an example of how to do it.
Here is how it is done in the SMAPI, this is defined in the sm_api.py file alongside the other function definitions.
smGetDeviceList = smlib.smGetDeviceList
smGetDeviceList.argtypes = [
numpy.ctypeslib.ndpointer(c_int, ndim=1, flags=’C’),
POINTER(c_int)
]Hi Matt,
We at Signal Hound don’t have experience with the IAS software, but I know several of our customers use it. Hopefully they are on our forums and can give you some good advice.
Andrew
JHoy,
If you are sweeping, you can set the software into ‘single’ trigger mode, and manually initiate and wait for the sweeps. Most of our examples use this approach. For example, the scpi_simple_sweep.cpp example shows how you can start and wait for a sweep to complete with one SCPI command. That way you don’t have to wait for your measurement to change. In this way, the sweeps are user driven and you can control and wait for when they update.
Regarding your other issue. Can you provide more details? It sounds like your device is disconnecting in Spike? and then your SCPI query times out? I’m not sure the Spike software would be able to provide continuity right now if your device is disconnecting during a SCPI query. I believe you would need to wait for the timeout and then re-query. If your device is disconnecting that often, we would probably want to troubleshoot that issue.
The API does not perform automatic calibration based on temperature drift. The user is responsible for this. You can perform this by reconfiguring the device (calling saInitiate). This will reconfigure the device for your measurement and update the temperature coefficients. If temperature drift is a concern, you would monitor the temperature returned from the API, and reconfigure the device once a measurable drift occurs. The Spike software does this when a 2C drift occurs.
Let us know if you have follow up questions.
Hello Miran,
Thank you for the report. We will investigate.
Andrew
February 10, 2022 at 8:09 am in reply to: Sweep recording – max file size Win10 64-bit vs. Linux 64-bit. Hi LRokos,
I apologize for the inconvenience. We will resolve this for the next version of Spike. Until then, you will be limited to the 1GB recording size on Linux when using the Spike software.
Andrew
Yes, it sounds like your understanding is correct. If you know the time of a specific PPS, and you know what I/Q sample it occurs on (information that our API provides), you can extrapolate timing to any sample. The PPS will appear in the I/Q stream each second, so you can continually correct for any drift/error.
The main advantage of using the internal ublox-m8 is convenience. In a multi receiver setup such as yours, what approach you take will likely depend on your timing requirements and/or hardware limitations (i.e. can you run 10M/PPS to every receiver).
The ext trigger example I mentioned can be found in the SDK, in the sm_series/windows/examples/c++ folder. It only shows you how to call the functions, it does not simulate timestamping. Programming specific questions are best directed to me via email, or if you need a more elaborate example.
Andrew