Thanks for the update. Glad you got it working.

MCarr,

The API does not have any of the modulation capabilities. When using the API you have to provide your own waveform. You have a couple options,

– The VSG60 UI can be programmed using SCPI commands. in the SDK, look under the SCPI folder and you will find a manual and examples for configuring the software via SCPI commands. Labview has support for sending SCPI commands. In this scenario, the VSG60 software would be running, and then you would run a SCPI “script” in Labview (or any other programming language) that would configure the software.

– Generate your own I/Q waveform. If you don’t know how to generate a QAM waveform, you could use offerings from Labview such as,
https://www.ni.com/en/support/downloads/software-products/download.labview-modulation-toolkit.html#484334
or MATLABs communication toolbox. If you generate the waveform outside labview, then you would want to save it as a file, and in Labview, load the file and feed it to the API.

Thanks for the requests RVanDyke. I’ll see if there is something we can do here.

The API certainly should be able to interface several devices. We interface up to 8 devices in our manufacturing line using the API. What you will find is that most PCs will limit the number of actively streaming VSG60’s to 2, primarily limited by USB throughput and CPU cycles. Some PCs do struggle to transmit on 2 simultaneously. If you are also using one of our spectrum analyzers, you might consider moving the analyzer to another PC for making measurements.

If you are on Linux, please be sure to read the section on Linux in the VSG60 manual,
https://signalhound.com/sigdownloads/SDK/online_docs/vsg60_api/index.html#autotoc_md9

Opening a second device should be as simple as calling vsgOpenDevice a second time with a new handle variable. This will result in you having two handles, one for each device. The handle values should be 0 and 1 after the vsgOpenDevice function returns.

If you are on Windows, you can verify that you see 2 devices connected in the device manager. If you don’t, then you need to resolve this first. The LED should also be solid green on both units when connected and idle.

We have not tested multiple devices in our Python environment, but it should be the same. If possible, you can test multiple devices in C++. The Python wrapper simply wraps the C interface. You can see the function assignment in the vsg_api.py file.

Tom,

We will be responding to these questions from our support email, thanks.

If the signal level changed by a non-trivial amount, I would consider that a bug and we could investigate further. It’s hard to tell from your picture since a lot of the signals are broad band. If you were ever able to inject a simple known signal like a CW for a test run, that would certainly make it easy to determine.

The gain/atten settings getting changed is very possible and likely the cause. Based on your other responses, it’s safe to assume this unit is exposed to the elements? (at least temperature variation) The Spike software will auto reconfigure the device when it experiences a 2C shift in internal temperature. That shift might necessitate different temperature corrections as well as a different gain/atten to maintain optimal measurements. If either the gain or atten changed due to that automatic update, it would result in ~5dB shift in the noise floor. The signal power of an input signal should not change (other than correcting any small amount of error that might have been present with the old temperature correction).

At room temp, I would not expect this auto reconfigure to occur once the unit has stabilized in temperature.

I know you are on an older version of Spike, but newer versions do allow you to disable the auto recal in the preferences menu. If you do this, you subject yourself to measurement errors if the devices drifts too far in temperature. You can also force the gain/atten, which would still perform the recalibration, but might not update the gain/atten to eek out more dynamic range when it could, or may not provide enough room for a full scale input. Both of these would be minor repercussions.

Very interesting Andrew, thanks for sharing. Do you know what old version of Spike you are running on this installation? Alternatively, do you know roughly what version you start having the stability issues with? It would be interesting to review the change log and code to see what changes might have affected this.

[Andrew]

We have a number of customers in the pro audio community. You might also try forums specific to those groups, like https://forums.prosoundweb.com/index.php
There is mention of our product on those forums, you might get more responses there.

Good luck!

• This reply was modified 3 weeks, 1 day ago by Andrew.

[Andrew]

The way that max hold works in Spike, is that each time a new sweep is performed, each bin in the sweep is max held with that same bin in the max held sweep.

Your algorithm might look like this,

1) Configure device
2) Capture first sweep and set as max hold sweep
3) Capture next sweep into variable “temp”. For each bin in the max hold sweep, set that bin to the max of either temp or max hold.

// Pseudo-code for #3
for(int i = 0; i < sweepSize; i++) {

  maxHoldSweep[i] = (maxHoldSweep[i] > temp[i]) ? maxHoldSweep[i] : temp[i];

}

4) Repeat #3 until desired number of sweeps or time elapsed, or after ping has been sent.
5) To determine the peak value in the sweep, simply iterate over the max hold sweep and look for the max value.

// Pseudocode for #5
int maxIndex = 0;
for(int i = 1; i < sweepSize; i++) {

  if(maxHoldSweep[i] > maxHoldSweep[maxIndex]) {

    maxIndex = i;

  }

}

double maxValue = maxHoldSweep[maxIndex];

Hope this helps

• This reply was modified 3 weeks, 1 day ago by Andrew.
• This reply was modified 3 weeks, 1 day ago by Andrew.
• This reply was modified 3 weeks, 1 day ago by Andrew.
• This reply was modified 3 weeks, 1 day ago by Andrew.

The RHEL8 version was updated.

Thanks

Tamantea,

1) Unfortunately the SA124 is not supported on Ubuntu. Spike itself will work on Ubuntu, but only with our other models. Neither the SA44 or SA124 models work under Linux, only Windows 10/11.

2) You can certainly try using a standard cable. In most instances it will be fine. But not all USB ports will be able to supply adequate power to the SA124 over a single USB port. If you experience issues, you will need to revert to the y-cable.

Let us know if you have additional questions.

AKumar,

We replied to your email that you also sent.

For other customers who are interested in this question, we recommend a GPSDO.

Hi Victor,

The RHEL releases are usually performed on customer request. Since I know you are waiting for some updates, I’ll try to get the release out this week. If you want to request a RHEL update in the future, you can reach out to me directly at aj@signalhound.com.

Thanks

RVanDyke,

This feature was added to Spike version 3.8.11.

Andrew

Hi Victor,

This functionality was added and will be in the next release of Spike.

Andrew

Hello RVanDyke,

The “Disable All” markers feature will be available in the next release of Spike. It will do just as you suggested, and simply deactivate the markers, leaving all other parameters the same.

Andrew

We have not tested any connectivity other than end to end SFP+ cables (fiber and short copper runs). Most of the customers who have tried converting to RJ45 have had intermittent connectivity issues that were resolved by switching back to fiber. Feel free to experiment if you already have the adapters, but expect it to have issues. We cannot recommend any RJ45 equipment at this time.

Hi Ermy,

The only units we output are the ones in the reference level unit selection, and the only linear unit is mV. I will see if this is something we can easily add in a future release. Thanks for the feedback.

Andrew

Hi Victor,

There is not any way to do this right now, I will see about improving this for the next release.

[Author]

Posts