Forum Replies Created
- Posts
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.
jyaron,
Yes, triggering for any I/Q acquisition other than the SM200B/SM435B 250MS/s I/Q capture mode needs to be performed in the customers application. There are no current plans for any firmware updates to the SM200C to enable this functionality on device. The SM200C does not have the 2 second I/Q acquisition mode that the SM200B does, it only supports full 200MS/s (with decimation) streaming. It uses the internal memory for buffering to support full streaming operation.
MATLAB did struggle to even maintain full 200MS/s rates in our testing, so I agree that performing triggering directly in MATLAB at the 200MS/s rate might be difficult. Consider building a small C++ wrapper around our API that performs the triggering that you can call into from MATLAB.
I will add this idea to our customer wish list. It would be interesting to add a triggering interface for customers who do not need streaming I/Q but would like a triggered capture instead.
I appreciate the feedback.
Andrew
Thanks for the feedback David. This is not currently possible but I agree this would be a useful feature. I’ve added it to our customer wish list. Right now, you would need to export both traces and compare them in a different program like excel/matlab/etc.
Andrew
RAlbert,
In sweep mode, ‘Power’ averaging will perform averaging in mW units and ‘Log’ averaging will average in dBm units.
In real-time, averaging is always performed in mW units.
There is a separate type of averaging when you select “Average” for your trace type, that will average the traces together in their final unit type, which is typically dBm.
Let me know if you have follow up questions,
Andrewjmatusiak,
Depending on the settings you are using, it can affect how much data is being transferred, how much processing is occurring, among other things. This can affect the stability of the data link. That being said, sweeps should be fairly stable for most configurations. I would like to learn more about your configuration and PC setup. Can you email me at aj@signalhound.com with the following information,
– your PC make/model/CPU
– your operating system
– what kind of SFP+ adapter/card you are using
– What values you are passing to these functions.I look forward to your response.
Andrew
GSingh,
Can you please email aj at signalhound dot com for support of this issue. When you email, please provide the following information.
– A picture of the configuration of the software at the time this issue occurs. We would like to try to reproduce this with the settings you are using.
– The make/model/CPU of the PC you are using.
– A description of how you are measuring the output of the signal. Are you using another Signal Hound product to measure the output? Can you describe your measurement setup?
We look forward to the response.
Andrew
Thanks for the feedback Cyprien.
While not exactly API support, there is already SCPI automation support for the LTE measurements. You could write a script to automate the measurement and pull measurement information from Spike. Full blown API support isn’t on the roadmap right now. Look in the SDK for the SCPI manual and examples.
Development on the BB60D is still moving forward. Dynamic range and phase noise have improved quite a bit, both contributing to better LTE measurements.
If you have any additional feedback on the LTE measurements, please reach out to aj at signalhound dot com.
Thanks