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

Hello Bruce,

On the PC where you are seeing the issue, how long is the device running in the software before you see this error message? Does it happen immediately/after a few seconds/a couple times of day?

Are you using the same USB cable for all your tests? If not, it might be worth trying a USB cable you know works on another PC.

You can try changing the PC power management options. Go to “Power Options” in the control panel and change your power management settings to “High Performance”. On Windows 10 this might require a few extra clicks to show the “High Performance” option.

At any point did the device work on this PC? Or did it start having issues after a Windows update?

Regards,

Hello Dragan,

I just emailed you the link for the API download which includes the manual. I will link it here as well.

https://signalhound.com/download/bbsa-application-programming-interface-for-windows-3264-bit/

A link to just the manual. https://signalhound.com/sigdownloads/SA44B/SA-API-Manual.pdf

Regards,
Andrew

[Author]

Posts