[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);
end

If you want to compare with Spike, ensure you use the same reference level.

• This reply was modified 3 years, 6 months ago by Andrew.

[Andrew]

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?

• This reply was modified 3 years, 6 months ago by Andrew.

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.

[Andrew]

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

• This reply was modified 3 years, 6 months ago by 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,
Andrew

jmatusiak,

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

[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

• This reply was modified 3 years, 7 months ago by Andrew.
• This reply was modified 3 years, 7 months ago by Andrew.

We built these OOT modules with GnuRadio version 3.7. With version 3.8 and newer there were several breaking changes, many relating to Python. If it’s possible to use an older version of GNURadio that will probably fix the issue. Otherwise it might be necessary to rebuild the OOT module for the newer version. Also, see this guide for porting OOT modules to 3.8 or newer. Some customers have followed this with success.

https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide

Andrew

lsullivan,

When average detector is selected, the averaging algorithm is used, when min/max detector is selected the IIR filter is used.

If you are able to provide more information about your measurement, we can try to help you determine the best settings for the device.

Andrew

Chuck,

Once you enter both the map and the lat/lon coords, you can use the import/export session to load/save both the map and coords simultaneously for future use. For my testing, I exported the session with map and coords before making any measurements, so I could quickly load a clean map on each startup.

In the case of mapping, the preset doesn’t store the map/coords, only the mapping session. So when you want to start up where you left off, load your exported session, and load a preset with the mapping settings you like.

Hope this helps!
Andrew

Chuck,

The import guide is located in the Spike installation directory at C:/Program Files/Signal Hound/Spike/manuals.

Let us know if you still have problems after looking through that.

Thanks!

Thanks for the feedback Tuong.

Thanks for the feedback Henry.

As of right now only channel power measurements are available in the RF mapping mode. We will look into P25 in the future as this is a highly requested measurement. I don’t have a timeframe on this at this time.

Andrew

Tuong,

This is not currently planned functionality. If you need this type of functionality, consider looking into our third party software vendors.

https://signalhound.com/support/third-party-software/

Some of these vendors support this type of measurement.

Andrew

Tuong,

There is no SNR measurement for the mapping functionality. Is there a certain type of signal you are trying to measure? Based on your other post, are you trying to perform a digital demodulation measurement to overlap on the map?

Regards,

Hi Stanley,

The Quasi-peak detector is currently only available in Spike. We don’t have any way to automate this measurement via an API at this time. If we provide anything in the future it would probably be through SCPI commands to Spike. We don’t have any plans to pursue this at the moment though.

I appreciate your feedback, if you would like to reach out to me via email at aj at signalhound dot com, I can contact you if we ever pursue this in the future.

Andrew

I’m not sure if we’ve used an external GPS with a ublox. Our SM200 uses this chipset, but we don’t interface it over serial as Spike does.

It is probably better in the short term to consider using a different GPS if possible. If you would like to email me at aj at signalhound dot com, I can keep your email and let you know if we are able to acquire the GPS you are using and get it working in Spike. Also, it might be interesting for us to add some debugging utilities to the GPS interface in a future release of Spike, and I can reach out if we ever add something like that.

I apologize for the inconvenience. Thanks for your patience and providing the information.

Andrew

[Author]

Posts