Forum Replies Created
- Posts
Sorry, it looks like I didn’t update the SCPI manual to reflect the change.
Try “FETCH:ZS? 10” for the average power.
Let me know if you run into issues or have follow up questions.
For future reference, when making channel power measurements, both ‘average’ detector must be selected, as well as ‘power’ video units. If either of these settings are not used, you will not get consistent channel power measurements.
Hi Jacks,
Unfortunately, I cannot reproduce the problem with the provided information. Would you be willing to email us at support@signalhound.com with more information about your issue? Please provide screen shots of the Spike software and descriptions of your setup and any signals you are generating/measuring. Hopefully we will be able to quickly troubleshoot and resolve your issue.
We look forward to your response.
Andrew
Good question,
Over the years, we have learned that using a single USB 3.0 type A port will generally be OK. PCs seem to supply adequate power to our device over a single cable. Places where you can see issues is with ultraportable devices like the Surface Pro line. If you only have a single USB type A cable and it does not supply adequate power, then we recommend a USB 3.0 hub that has external power.
If you only have a USB type-C port, you will need to use an external hub that performs power negotiation/use external power. A hub such as the Anker hub linked below has been reported to work with our devices. Using a direct type-C to type-A adapter usually will not work, we believe due to power issues.
https://www.amazon.com/Anker-PowerExpand-Adapter-Delivery-Ethernet/dp/B087QZVQJX
Andrew
1) When using the I/Q recorder the scale factor is not recoverable, so you will have to use the data as full scale if saving as 16-bit ints. If using the API you can store the scaling factor separately and use it to convert to dBm if needed. The reference level being used as the scale factor does not apply with the I/Q recording utility.
2) Check out the docs for more information on scaling, we use this approach for both our BB and SM line of receivers. I/Q values have a similar scale as a voltage, but need additional conversion if you want to use them as a voltage.
https://signalhound.com/sigdownloads/SDK/online_docs/bb_api/index.html#IQDataTypesAndrew
1) My guess is that 0 duration just means the event lasted for a single sweep, and 0 bandwidth means that only a single point in the sweep exceeded your threshold. Does that line up with what you are seeing?
2) Using the recorder in Spike means that you would only have to write code that parses those files and looks for events. Using the API gives you more flexibility to write files in a format that’s better for you, and also you can automate more of the recording process vs manually saving the files in Spike. It’s the same underlying data/samples in both approaches.
Our data rate is 160MB/s. Using the API you can choose whether to receive 16 or 32-bit complex values. The 16-bit are shorts, and 32-bit are floats.
Retrieving I/Q data via the API is by default continuous. If you set the purge flag to false, the I/Q data will be continuous. The API stores about 1/2 second worth of I/Q data internally, so you must not let this internal buffer “wrap/overflow/etc”, otherwise you will have a gap in samples. You must continually poll the API for the duration of time/samples you need. You can detect gaps by monitoring the sample loss parameter and the status flag returned from the bbGetIQ function. You can request arbitrarily large buffers sizes from the API if desired. If you plan on streaming for long periods of time, I suggest requesting buffer sizes around ~1/60th of a second. This is still a small enough buffer to quickly allocate and does not call into the API (which has a small amount of overhead) too many times per second.
Andrew
Hi BDick,
The limit line amplitudes you listed are in positive dBm. I suspect you meant for them to be negative? (-50, …) Right now the limit line is being drawn off the top of the screen.
Andrew
Michael,
You will have to change the algorithm slightly.
I would continue to sum everything as linear units, and then divide through by the window bandwidth which can now be calculated with the following equation.
nWindowBW = RBW / BinSize;
Where RBW is what you asked for, and bin size is the frequency spacing between the sweep bins.
This should get rid of most of the variables used to calculate nWindowBW in your above example.
In the past we used a variable bandwidth flattop window, but now we use the standard flattop window with zero-padding to achieve arbitrary RBWs. This is a more traditional approach to arbitrary RBW selection.
Andrew
Thank you for the pictures Michael. I was able to find the reason for this difference. It is a processing change that was made last year. We altered how we process sweeps for flattop RBWs with the BB60. It should not have any effect on your measurements.
Let me know if you have follow up questions.
Andrew
Michael,
I am unable to reproduce this issue. I’m assuming you are using a BB60 device?
Are you using different RBW shapes? Going between Flattop and the Nutall window would account for an factor of 2 difference. If I use your settings with a flattop window, I get 64k points, if I use a Nutall shape, I get 32k points.
Andrew
Hello Ajaykumar,
Look in our Spike software manual (linked below). In section 4.14.5, we provide a measurement walkthrough for our WLAN measurements. This should provide you with several steps for setting up the measurement for the first time. To get a nice looking constellation you will have to use our WLAN measurement mode. No other measurement mode in the software will show you a constellation of a Wifi signal.
https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf
Andrew
The FFT processing is done in software. There is processing time associated with each sweep and there is blind time between sweeps where events can be missed. This is a general shortcoming of swept based spectrum analysis, and if your goal to capture 100% of short duration events, measurements like real-time and I/Q streaming are required.
Andrew
Hi Jing,
The interference hunting mode is not a real-time measurement, it operates using standard sweeps. This means for short duration events like the ones you are measuring, you can miss them. Increasing the RBW can help improve sweep time.
If all of your events are within a 27MHz span, you can use our real-time measurement mode to be able to visualize all events in the frequency domain, and use our sweep recorder to capture these events. The data format for the sweep recording is different than the recorded data in interference hunting mode, but all events that have 2ms duration will be visible.
You can also record events in zero-span using the I/Q recorder in zero-span mode. You can set up a video trigger and capture a sequence of I/Q time domain files that should contain a significantly higher percentage of the events than you capture in interference hunting mode. Depending on how the pulses arrive, it may not capture 100% of them.
Another option is to use the API in I/Q streaming or real-time mode to capture data and programmatically store the events of interest.
Andrew
Thanks for the additional feedback!
Andrew
There is not currently a way to extract that value. It is something I could add relatively easy (I believe) for the next release of Spike.
In the meantime, if you are retrieving the I/Q data, you can make this measurement with the equation
10*log10(mean(I^2 + Q^2));
In spoken word, calculate the linear power of each I/Q sample, I^2 + Q^2, calculate the mean of the linear powers, then take the 10*log10 of that mean.
This would give you the average power in dBm over the sample interval of your choice.
Given this, would you still be interested in a SCPI command to retrieve this value?
I look forward to your response.
Jing,
We do not sell or provide antennas with our products. You will need to reach out to whom you purchased our products to find out what antenna they provided you.
Andrew
Tuong,
The I/Q recorder in Spike is not open source. That being said, we could look into extracting some useful code from the recorder as an example for customers to use. I will consider what this would look like.
We have a much older open source recording utility that was written for the BB60A/C many years ago. It illustrates multi-threaded recording of full IF/IQ data. It will likely not compile against our current APIs, but it might be helpful for you.
https://signalhound.com/sigdownloads/BB60C/BB60_Demos.zip
Andrew
Thanks for the feedback. We are continually evaluating ARM as a target. It is unfortunately more involved than a recompile (otherwise we would definitely have done it!), there are large amounts of x86 specific code that need to be rewritten/refactored for ARM.
Andrew
We currently do not support ARM based CPUs for any of our products. Our devices are recommended for use with Intel x86/x64 CPUs.
Andrew