Forum Replies Created
- Posts
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
If you can run a GPS antenna to the unit, you can get the API to performing timing for you. Enabling the smSetGPSTimebaseUpdate() allows the internal GPS to discipline the timebase of the unit. While the device is open, you can query the state of the lock with the smGetGPSState() function, you can wait for ‘disciplined’. Once disciplined the timestamps you received from the smGetIQ() function are referenced to the GPS. Technically you can get timestamps without the disciplining, but you will see timestamp drift between PPS’s.
If you want to do this manually with an external 10MHz and PPS, tell the instrument to use an ext 10MHz timebase with the smSetReference() function and connect the PPS to the trigger input port (and the 10MHz reference to the 10MHz ref input). Then when streaming I/Q, the PPS events will show up in the trigger output buffer. Its then easy to timestamp samples based on their location relative to the PPS trigger position in the stream. With this method though, you will have to acquire and parse the NMEA data from the GPS to know the absolute time of the PPS event. The advantage of doing this externally is being able to use higher accuracy GPS receivers than our internal one, and running multiple units off of one external GPS which will have better precision for certain tasks.
We have an example for the first method discussed above, but not for the second. We only have a generic ext trigger example which you can view to see how the triggers come in. Hopefully the explanation is enough to piece the rest together. If you have follow up questions as you work through this, please let me know.
Spectrums via the API sweep configuration are timestamped when using the internal GPS, but due to how we process the sweeps, it will be hard to get precise timing on an event in the sweep. It should really only be used as a coarse monotonically increasing timer. The I/Q sweep list functionality in the API allows you to sweep the I/Q acquisition with the same speed as our fast sweeps. Timestamping with the I/Q sweep lists only works with the internal GPS (rather than providing an ext 10M/PPS), but this approach would give you precise timestamped ‘steps’ of I/Q samples. The downside, is that you would have to FFT and construct the sweep if you wanted the classic sweep plot as well.
You can email me directly at aj@signalhound.com if needed.
Andrew
Jared,
All of our products are only supported on x86/x64 systems. The SA124 is only supported under the Windows OS. We have not attempted to use GNURadio under Windows with any of our devices. I’m not sure what OOT module support GNURadio has on Windows. Our BB60 and SM200 line of analyzers are supported under Linux and can be interfaced from GNURadio. We have some OOT modules for these devices on our github page. They need to be updated to GNURadio 3.8 and do not work out of the box right now.
https://github.com/SignalHound
Andrew
Can you post the configuration of the VSG60 software at the time of failure? It sounds like you are keeping the configuration the same except changing the output level? We can try to reproduce the issue here and see if it is software related. Anything else you can provide that could help up reproduce the issue here would be appreciated.
Other ideas. Have you tried your test on a different PC, to rule out any issues specific to this PC?
What is the make/model of the PC you are using?
Please email me at aj@signalhound.com with your response if it is more convenient. You will also get quicker responses via email.
Andrew
Consider doing your own FFT and windowing with something like the flattop window. The pwelch function uses the Hamming window which has ~1.8dB of scalloping loss and could easily account for most of the error you are seeing. The flattop windows has ~.1 dB of scalloping loss, and is much more appropriate for amplitude accuracy, and is likely what Spike is using in your measurements.
Here’s some example code for generating your own spectrum
function [spectrum] = calculatespectrum(t)
%CALCULATESPECTRUM
% Return the log spectrum of the input time domain signal
% The input is a real or complex column vector of floating point values
window = flattopwin(length(t));
if(~isreal(t))
window = complex(window);
end% Normalize window
scalar = length(window) / sum(window);
window = window.*scalar;spectrum = fftshift(fft(t.*window)./length(t));
spectrum = 10 * log10(abs(spectrum).^2);
endIf you want to compare with Spike, ensure you use the same reference level.
Can you share the script you are using to calculate I/Q power? How are you measuring power in Spike? With the standard sweep mode and markers? Are you using the default Spike configuration (full 20GHz span on bootup)? Or have you modified any settings in Spike?
The 32-bit floating point I/Q data has the corrections applied. It is scaled to dBm. You can read more about this in the API manual in the I/Q data types section. If you are doing an FFT on the I/Q data, ensure your are normalizing your window function and properly scaling the output of your FFT. You should be able to simply do a log power conversion of the FFT results to get dBm.
Andrew
Good idea. You could use the limit line to visually see the previous trace. You would want to ensure you export the trace as MHz (see preferences menu). Then load the exported file back in the limit line manager. No need to offset the trace if you don’t need to. With the limit line, you won’t be able to place a marker on it, but it would give you a visual.