Hello Mirek,

Thank you for the feedback. I can comment on some of your points.

1. The “N points in M ms” display you are referring to shows the number of points in the sweep as well as the amount of time it took to acquire and plot the sweep. ‘M’ in this display is the sweep time.
2A. There is a sweep time control in the ‘Acquisition’ section of the sweep settings control panel. You can find this on the lower right of the application window (assuming you havent moved the control panels from their default position. Keep in mind, for a digital FFT analyzer we define sweep time as the total acquisition time for the sweep. It will not match the sweep time displayed on the graticule as that sweep time will include processing and display time in addition to acquisition time.
2B. See #1 above. ‘N’ in this display is the number of points.
3. You cannot control the number of points directly in our software. Only indirectly through the RBW and span settings. Sweep size is roughly going to be equal to 5*(span/RBW) for the flat top window. Other spectrum analyzers that allow you to control the sweep size are doing so by ‘binning’ adjacent frequency points. We do not do this, so when you go to export/record the sweep you still have the full resolution from the original sweep.
4A. This is a good suggestion but would require additional hardware development to perform and thus we won’t be able to offer this on our current spectrum analyzer line up.
4B. To load the default settings only, use the Presets->Load Default Settings control. This will retain your current measurment mode, but will go back to power on settings. To fully reset to power on state, set the analysis mode to Sweep and hit the “Load Default Settings” file menu selection.
5. This is a good suggestion and we have considered adding this functionality to Spike. We do not have a current time frame on this functionality, but it is something we are very much interested in. Most likely we will add this through a SCPI backend in the Spike software.
6. I agree this will be useful functionality when we add this. If you were not aware, we do have programming interfaces for our spectrum analyzers. They are in the form of C DLLs for Windows. Currently customers who need remote/programmatic control of our receivers use these DLLs to develop out thier needs. I realize this is not as convenience as an ethernet SCPI aware Spike application, but it is something we currently offer.

Thank you very much for your feedback. Let me know if you have additional questions or comments.

Regards,
Andrew

[Andrew]

Hi pmerana,

Currently there is no way to automate the quasi peak measurements. It must be done manually as you say. I think this is a good suggestion and it might be something we can add to our software in the future.

Side note: In addition to setting the QP frequency manually, you can select a spur in the peak table list and move the spur frequency to the quasi peak frequency entry with the “Selected Spur to Meter” button. You can do this while the QP measurement is active, and you can move the QP measurement to the meter readings table with the “To List” button while the QP measurement is active as well.

I apologize for the inconvenience. Thank you for the feedback.

Regards,
Andrew

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

Hi Fabrice,

So, what’s going on here is that the API is limiting the IF bandwidth to 50kHz and the GUI is not showing you the clamped value. If you opened the spectrum plot in zero-span you would notice that as you decrease the bandwidth past 50kHz it is being limited. (IE you wouldn’t notice a difference spectrum at 10 and 50kHz bandwidth)

The proper fix here is to have the GUI report the bandwidth that was clamped. The reason there is IF bandwidth limits here, is due to the filter sizes required to get reasonable rolloff at very narrow bandwidths. There are fixed sized filter passes on the downsampling processing in the BB60C API.

If you are able, a workaround is to simply lower your sample rate to something closer to 10kHz. 50kHz bandwidth is less than 1/10th the sample rate you are using. A good target might be between 1/2 and 1/4.

I realize it may not be a viable option, but we do have a programming interface for the BB60C. If you need a very specific setup, polling the IQ data from the device into your C/Matlab/Python/other program, and then filtering down to 10kHz can be straightforward. Then you can save the data in whatever format is best for your application.

Again, open up the spectrum plot to visualize where the lower IF bandwidth cutoff hits. I can make a note to fix the GUI to show the clamped values.

I apologize for the inconvenience. Let me know if you have further questions or feedback.

Regards,
Andrew

dkosek,

Very interesting. Thank you for the follow up. We have seen this before on desktops, where certain USB ports work fine while other (typically front panel ports) cannot run the BB60C. I’m glad you were able to get it to work.

Regards,
Andrew

Hi Testpoint,

I agree with Jared. Tools like Matlab (they do have an LTE toolbox https://www.mathworks.com/products/lte-system.html) will be the best way forward. I’m not aware of any third party applications that solve this problem directly using our receiver. As Jared stated, you will need to pull the IQ data directly from the receiver (using the BB60C API) and push it through some processing libraries. There are Matlab examples for getting IQ data from the BB60C into your Matlab script, you can find these examples in the API SDK. (link: https://signalhound.com/download/bbsa-application-programming-interface-for-windows-3264-bit/)

Regards,
Andrew

Vincent,

When the ref offset is zero, the CW peak you measure in the software should be equal to what is on the input port. It sounds like this is the case for you based on your first message? Changing the max input should not affect the CW peak reading (assuming you only use values above the input level). You can contact me directly at aj@signalhound.com if you have further questions.

Regards,
Andrew

Hi Vincent,

Max input directly controls the sensitivity of the receiver. For the best sensitivity max input should be set to ~5 dB above the maximum possible input level. The receiver can clip signals at or above the max input level. The software will warn you with a signal is clipped.

Ref offset is a convenience control which adjusts the sensitivity of the receiver to account for external attenuation/gain. IE, if you attenuate the input signal by 10dB (pad), setting the ref offset to +10dB will account for this and adjust the receiver sensitivity accordingly.

Let me know if you have additional questions.
Regards,
Andrew

Hi Henrodog,

Thanks for the feedback! I will look into this.

Regards,
Andrew

Me and Cory have Lenovo Thinkpads (for personal/home use)
At work we have used Dells/Thinkpads/Toshibas/Acers/Asus.

I think the business lines and mid-higher end models from each company are more or less comparable.

Regards

Hello Cristian,

How are you measuring the frequency offset? Are you in sweep measurement mode and using markers? If so, what is your RBW?

Can you verify the frequency offset using tools such as the Utilities->Frequency Difference meter, or the carrier offset readout in Analog Demod measurement mode? In both measurements you will want to set the center frequency and reference level for your input CW.

I look forward to your response.

Regards,
Andrew

Hi Jom,

(BB60C/A only)

In theory there is lower processor requirements for regular sweep measurement mode, (at the expense of longer sweep times) but we still recommend dual core i5 processors at a minimum. Without this minimum processor anything that takes advantage of IQ data (zero-span, audio demod, analog demod, digital demod, or real-time analysis will risk dropping data and giving incorrect results.

Regards,
Andrew

Dragan,

The API does not perform the sweep averaging you desire.

To accomplish sweep averaging, you will need to acquire N sweeps and accumulate them into a single sweep (add bin-by-bin) and when finished divide each bin by N.

Let me know if you have additional questions.

Regards,
Andrew

Hello Miran,

Thank you for your feedback. I think this is a reasonable request and I agree. I will make sure this is in the next release of Spike. We do not currently have a time frame on the next release.

Let me know if you have additional comments or questions.

Regards,
Andrew

Hi Chuck,

Assuming 50 ohm, and the Hz in dBm/Hz and nV/sqrt(Hz) is 1Hz, you can simply perform the conversion from dBm to nV.

nV/sqrt(Hz) = 10 ^ ((dBm/Hz + 166.9897) / 20.0);

If you have access to Matlab/Octave, an anonymous function can make quick conversions

>> myconversion = @(dbm) 10^((dbm+166.9897) / 20.0);
then later

>> myconversion(-160)
ans = 2.2361 

Regards,
Andrew

Hi Troy,

Yes, this is very likely related to the GPU. We utilize OpenGL to raster several of the displays and require at minimum OpenGL 2.0 support. Support for OpenGL 2.0 in hardware has been around for ~8 years so for a 1 year old laptop to have trouble with this is odd.

The first thing I would try is updating drivers. Look on your manufacturers website for any potential graphics/display drivers. You can also try updating them directly through the display manager. You can also update drivers through ‘Windows Update’ (keep updating until it can’t find any more updates).

If this does not resolve your issue, let me know what PC you are using (make/model/CPUmodel) and I can help you find drivers direct from the parts manufacturers. You can reply here or to my email at aj@signalhound.com

Regards,
Andrew

Andy, If we modify some aspect of the layout (internally) some aspects might revert to the default state. You should be able to resize it quickly and the software will remember the size next time you open the software. Let me know if it is not doing this.

Andrew

blackmore90,

There is no notion of falling behind or not being able to process sweep data fast enough for the BB60C. For any given sweep there is a fixed amount of processing that needs to take place, the Atom processor will simply take a bit longer to do this compared to others, which means that in your sweep loop test code, more time is spent processing per sweep so you see the CPU usage increase.

The CPU usage numbers you are seeing look normal, as you are simply in a busy loop by telling the receiver to sweep as quickly as possible. If you wanted to reduce power consumption or reduce CPU load you could introduce a delay between each sweep. This would average out your CPU usage to a smaller number.

Let me know if you have additional questions.

Regards,
Andrew

Hello blackmore90,

The Vtune report is probably not reporting symbols properly, as the bbGetTimebaseCorrection function appears in there erroneously, although I would expect both the log function and the fft functions to appear at the top of the list.

The API should be idle between bbFetchTrace function calls yes? The bbFetchTrace function will perform the full acquisition and processing necessary to get you the sweep requested. Very little processing takes place on the receiver. The receiver sends ADC IF samples to the PC for further processing, which includes potentially hundreds/thousands of FFTs, logarithmic, and arithmetic functions on the data. The processing is also spread out on several threads to finish the processing as quickly as possible. If you are continually requesting sweeps the API will be continually processing these sweeps as quickly as your computer will allow.

If you think you are seeing behavior outside of this, we can investigate further. I don’t see anything suspect in your code snippet.

Let me know if you have further questions.

Regards,
Andrew

Volker,

The VSG and SA could be controlled at the software level to step/sweep, but would be very slow. The sync port on the TG is what allows fast step time at the firmware level. This was not part of the VSG design.

Regards,
Andrew

Hello gmdusa,

Email me at aj@signalhound.com with the serial number and model number of your device. If you have an older device (with no internal flash) then it is trying to pull the cal file from our server, but sounds like it is hanging up on the network request for some reason. I can send it to you directly. Once it’s on your system, that message should go away.

Regards,
Andrew

[Author]

Posts