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

Dhivagar,

Please see the SA124 product manual (linked below) in section 2.4 for more information about the IF output. This feature allows the SA124 to be used as a downconverter, and in this case, the 6MHz RBW refers to the bandwidth of the IF output. This should not be confused with the 6MHz sweep RBW available through use of a power meter.

https://signalhound.com/sigdownloads/SA124B/SA124B-User-Manual.pdf

Regards,
Andrew

Dhivagar,

Our software does not perform automatic IP2/IP3 measurements. They will need to be performed manually in the standard sweep measurement mode. We specify IP2/IP3 for the SM200 and provide typical values for the BB60C. You measurement may be limited by the performance of our receivers.

Regards,
Andrew

Sarath,

The Spike software does not have LoRa demodulation capabilities. You would need to use either a third party software platform that supports LoRa measurements (I am not aware of one) or use the API to retrieve the I/Q data and perform the measurement yourself. Additionally, the bandwidth of the SA44B is 250kHz, so you would at least have the bandwidth necessary for the 125 and 250kHz waveforms. I am not familiar with the LoRa standard and am not able to tell you if the SA44B is adequate for LoRa demodulation.

Regards,
Andrew

[Andrew]

Hi Keith,

Using our software there are a couple things you need to know about the signal before you can make a WLAN measurement. You need to know the center frequency, modulation type (A/B/N/AC), and signal level. The suggestion to use sweep mode is to help customers who may not know the center frequency. If you already know the channel, you can select it in the frequency control group in WLAN meas mode. Channel 36 can be found under the 5GHz Ch. drop down menu. Then you need to know the signal level to set the trigger level. You should use the AM vs time (search) plot to set the correct trigger level. This plot runs even if no signal is found and can be used to monitor the AM levels over time. You want to set the trigger level between the noise floor and the signal on level. Too low and you will always trigger on noise, too high and you will always get the trigger not found message. Finally, you need to set the Standard. If you know it, great, otherwise trial and error is an easy option.

I’m going to follow up via email as well. Let me know if you have follow up questions.

Regards,
Andrew

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

Hi Labbench,

We are actively working on it! 🙂

I suspect an early January release date. I will put it in the SDK when finished. Check the SDK page periodically.

Thanks!

Dhivagar,

I’m not familiar with GPS, but I believe the sample rate needed is 5MS/s or less, so I believe the VSG60A could generate a GPS signal if you used other software to generate the GPS waveform. We have no plans to create such a software at this time.

Regards,
Andrew

[Author]

Posts