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, 5 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

Sarath,

The SA124B is not compatible with Sceptre. The SA124B does not have a supported Linux interface and as far as I’m aware Sceptre is mainly supported on Linux.

Regards,
Andrew

Kefei,

Unfortunately we do not have any examples of performing this type of processing in MATLAB. I would start by learning about FFTs and the role of window functions for the FFT. There is a lot of literature available on the internet on this topic using MATLAB as the programming language. MATLAB has several functions to assist in this type of processing.

Overlapped FFTs as described in Justin’s response are how Spike converts I/Q data into a series of closely spaced spectrums.

Regards,
Andrew

Thanks for the follow up. I see how that could be confusing. Let me know if I can help with anything else.

[Andrew]

Hi Mike,

You are correct about the float* parameter. It should be const, and the data is not modified by the API. I will see about getting this in a future update. Yes, you are safe to cast.

I can’t reproduce the issue you are seeing regarding RF output on/off. I wrote a short script to attempt to reproduce. Maybe you could try to run this? If all else fails, maybe you could whip up a simple script I could try to run and reproduce? See code below.

This function simply turns on and off the RF output in 1 second intervals. I observed the power going on and off at these intervals.

void testRFOutput()
{
    int handle = -1;
    VsgStatus vsgSts = vsgOpenDevice(&handle);
    if(vsgSts != vsgNoError) {
        printf("Unable to open VSG\n");
        return;
    } 

    vsgSetFrequency(handle, 1.0e9);
    vsgSetLevel(handle, -40.0);

    while(true) {
        vsgSetRFOutputState(handle, vsgTrue);
        vsgOutputCW(handle);
        Sleep(1000);
        vsgSetRFOutputState(handle, vsgFalse);
        Sleep(1000);
    }
}

Look forward to your response.

Regards,
Andrew

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

rconaway,

Thanks for calling in, it was nice talking to you on the phone.
Let us know if you have follow up questions. You can email us at support at signalhound dot com.

Regards

rconaway,

It is possible to to record audio in the audio player, but the audio parameters must be entered manually. What do you mean by ‘lock’ to analog audio? If you have a programming background you might be interested in the API which will give you access to sweep measurements and audio. You can find the API in the SDK on our website. Additionally, the BB60C is not capable of performing a sweep and audio demodulation simultaneously.

Let me know if you have follow up questions.
Regards

[Andrew]

Hi Squiggles,

The main reasons we went with the micro-b is size (board space) and it is rated for more mating cycles. Type C wasn’t common when we released our first USB 3.0 product.

Regards

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

Testpoint,

We are currently evaluating options to reach ~44GHz for 5G frequencies. We have no definite plans as of yet. Check back maybe later this year.

Regards,
Andrew

Hi Peter,

Thanks for the feedback and input. The reference offset was moved to the file menu because it is now being used across most measurements in the software, as opposed to just the sweep modes in prior versions of Spike. Rather than have a separate entry for each measurement we put it in a global location. I apologize for the confusion there.

As far as the limitation on disp ref in harmonic measurements, it is an arbitrary limitation that I can remove in the next release. To get around this limitation, you can always simulate what the software is doing with a reference offset. For example, with a 50dBm input and 40dB ref offset (with 40dB atten), you can simply set the input level to (50-40 = +10dBm) and ensure the ref offset is 0. This will ensure the receiver settings are the same as with the ref offset, but then you will have to add 40dB to your measurments…

Regards,
Andrew

Hi Andrew,

Thank you for the feature request. I have thought about this feature before, and while I think it would be a good feature to have I’m not sure when we will be able to implement it. I’ll make a note you are looking for it.

Thanks again for your feedback!

Regards,
Andrew

Hi Andy,

What behavior are you seeing now? Looking at the code, it looks like it should already be doing that. It looks like it should mark the output sweep with an ADC overload if any of the sweeps that contributed to it had an ADC overload condition.

Look forward to your response,
Andrew

Hi Labbench,

We have an 64-bit Ubuntu 18.04 build for the VSG60A in the SDK now.

Let me know if you run into any issues.

Regards,
Andrew

[Author]

Posts