Hi Flo,

It looks like we use the default print resolution which is 6 digits after the decimal. I can look to change this in a future release to print more digits after the decimal, or change the units to Hz.

I apologize for the inconvenience.

Regards

Mikeh,

Which one of our spectrum analyzers are you using? I will try to reproduce this with your model specifically.

Mike,

If you are not currently using the latest version of Spike, is it possible you could update to determine if that is why this is not working for you? I am seeing success with this in Spike 3.5.5.

Regards

Hi Mike,

Yes, the reference level offset is saved in presets. If you save a preset with your desired reference level offset, you can quick load it next time you launch the software using the ctrl+N shortcut.

Regards

Hi Joe,

The v2.12.00 driver you are referring to is for the SA and TG devices. It does not affect the BB60C device. The BB60C USB driver is installed during installation and has not changed since release of the BB60C.

Again, if you would like to dig deeper into this issue, feel free to email me.

Regards,
Andrew

[Andrew]

Hi Joe,

Which version of software did you update from? The last couple of versions have not introduced BB60C changes.

Can you provide a screenshot of the frequency offset including all settings? I can try to recreate the issue on my end.

We haven’t introduced a frequency offset setting yet in Spike.

The reason you see the “To Center” behavior is because the RBW is changing as you decrease the span. The frequency accuracy is subject to the RBW. As you decrease span, the frequency accuracy gets better, which is why you see an offset as you decrease span.

Feel free to follow up with me via email and we will look at your BB60C frequency offset issue.
aj at signalhound dot com

Regards

• This reply was modified 5 years, 4 months ago by Andrew.

Hello rcidade,

You will need some software to generate or receive protocol specific waveforms. We are not familiar with DMR standards.

You might review some of our third party software vendors to see if they provide the functionality you require. I would start by looking at the Decodio software.
https://signalhound.com/support/third-party-software/

Regards,
Andrew

Thank you for the bug report Gary. I will be looking into this shortly.

Just as some more information I can attach to this bug report, can you let me know what CPU is in this PC?

Awesome Gary! Glad everything is working great.

If you come across any issues, please let us know.

Thanks for the feedback.

Andrew

Jason,

You may contact support@signalhound.com if you are unable to resolve this. If you do, please provide as much information as possible.

Regards

Jason,

The BB60C DLL also relies on the ftd2xx.dll. Is that also present? We include it in the SDK alongside the bb_api.dll.

Hello Kefei,

If you need to record a series of spectrums, you have a few options. You can used the sweep recording toolbar in Spike (in the sweep measurement mode). You will find the toolbar along the lower part of the Spike application in sweep mode. The file saved is a custom binary file which can either be played back through Spike, or could be parsed programatically. An example C++ parser is in our SDK.

You could also use the SM_API to programatically sweep the SM device and store sweep in whatever format you wish. The SM_API is a C++ DLL for Windows or Linux you can use to control the SM200. You can find this in our SDK. (Software menu on our website).

Regards,
Andrew

Hello jatwood,

The data array should be populated with values between [0,SymbolPositions-1]. For example, for a QAM16 signal, you will pass values between [0,15]. The symbol mappings are in the VSG User manual found in the VSG25 installation folder.

In the UI, we generate a bit string according to the PN sequence and then convert the bit string to symbol positions. For example, for a QAM16 signal if the random bit stream is 00101110, we would convert this to two symbols 0010, 1110, and pass an array of two data symbols to the API, [2, 14].

I apologize, we don’t have any LabVIEW interface for the VSG25.

Regards,
Andrew

Cristian,

In sweep and real-time mode only linear scale x-axis plots are available.

Regards

Our BB60 and SM200 spectrum analyzers are compatible with Linux. The SM440 will also be compatible with Linux.

[Andrew]

Hi Testpoint,

As a follow up.

We have started work on a SM model that will go to 44GHz, that we currently naming it the SM440B. We are anticipating release Q2 2021. Please check in periodically, we will have more information as we continue development.

Regards,
Andrew

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

Hi Serpi,

Yes, we have seen issues with bulkhead connectors in the past with USB 3.0. Our USB 3.0 devices requires high throughput real-time zero data loss links over USB 3.0. This usually limits cable length and additional connections, like bulkhead connectors.

If you need longer cable lengths than the typical 1-2 meter cables look into some active USB 3.0 cables. Here are some that other customers have used with success.

• SIIG USB, 3.0 Active cable, 20 meters.
• Cable Matters, Daisy chained 2 10-meter active cables.
• Corning, USB to optical, 20 meters.
• Firenex-uls-05, USB 3.0 active repeater cable, 5 meters

Regards

bbowar,

Email me at aj at signalhound dot com. I can be sure to contact you via email if we decide to pursue this in the future. I don’t think we have the resources to pursue this at this time.

Regards,
Andrew

bbowar,

We do not have any 32-bit Linux builds for our APIs. We compile on 64-bit Ubuntu 18.04 and CentOS7. We have no plans to target a 32-bit Linux OS at this time. I will make a note that you have requested this.

Regards

Kaiser,

I can give you estimate numbers for configuration switch times for I/Q streaming and segmented I/Q for the SM200B.

– I/Q streaming reconfiguration times are going to be between 15-60ms (which includes a small I/Q acquisition at each configuration) depending on decimation (longer for higher sample rates) and the I/Q queue size (see smSetIQUSBQueueSize). I achieve 15ms switch times with decimation 8 (bandwidth = 5MHz) and queue size of 5ms, and 60ms with decimation 1 (bandwidth = 40MHz) and default queue size (41ms). Smaller queue sizes are less resistant to USB data loss, but for short acquisitions, this is probably not a problem.

– Segmented I/Q reconfiguration times are ~20ms (which includes a small acquisition at each configuration). Segmented I/Q captures are limited to 160MHz bandwidth, so if you are trying to reduce noise and measure specific signals, you will need to further tune, filter, and decimate the I/Q data.

I’m not entirely sure I understand the noise issues you are having. If the SNR is low, and you need to know amplitude variation over short time intervals, consider decreasing ref level to -20 or below (if you haven’t already), performing I/Q streaming using a bandwidth that only includes your signal of interest, and performing overlapping FFTs with very high overlap rates. This can get you microsecond level resolution on your spectrums. You can play with this idea in our Spike software in zero-span mode with the waterfall plot.

If you just need to know the power of these signals over time, and SNR is low, you could measure channel power from the sweeps (which would help with noisy signals), or use I/Q and do an AM vs Time approach, and calculate power over a duration of time domain samples.

Some customers use a search/handoff approach. One receiver scanning and another measuring signals of interest reported by the search receiver. This way there is no blind time on the search receiver.

I hope you get some other feedback.

Regards,
Andrew

[Author]

Posts