Search Results for 'api'

[Justin Crooks]

Mcline,
If you look in vsg_example_complex_freq_hopping, you’ll see vsgSubmitIQ(). You could output a trigger pulse by adding vsgSubmitTrigger(). The API sends them to the VSG in the order received. So if you Submit some I/Q data, then submit trigger and then more I/Q data, the trigger’s rising edge will match the first sample of second chunk of I/Q data.

[mcline]

Thanks Andrew. I checked the SDK(06_21_21):
\signal_hound_sdk\device_apis\vsg60_series\win\examples\cpp, and only found reference to basic_generation, complex_freq_hopping, and open_device. I did not find any examples for triggering.

[Andrew]

This is an area we will be improving soon. The next version of the VSG60 software will improve the usability of the external within the main application.

Right now though, there are 2 ways to take advantage of the external trigger.

1) Use the API. The API manual documents the trigger functionality and we provide an example of using the trigger in C++. This information can be found in the SDK download.
2) In the main application, certain modes, such as pulse, ramp sweep, all digital modulations, and ARB output will output an external trigger. When any of these modes are configured with “Single” triggering enabled, each press of the trigger button will output the RF waveform synchronized with an external trigger event.

In the next release of the VSG60 software, the external trigger will also work when those output modes are configured in “Continuous” trigger mode, outputting a trigger on every loop of the configured RF waveform.

If you have follow up questions, let us know.

Andrew

[Andrew]

The VSG60 does have SCPI support. It is through the VSG60 application. You would launch the app on the remote PC, then you would be able to use SCPI to control the app (socket interface, default port 5024). The app does have a generic ARB mode, it will load several types of custom I/Q waveform files such as binary, CSV, wav, and some others. The ARB mode can be fully controlled via SCPI, including loading files. With this approach, your waveforms would have to be stored in a file.

The API will only communicate with a locally connected device. To use this in the same fashion, you would have to build some sort of local application that controls the unit and awaits commands from your remote script. This might ultimately provide more flexibility at the cost of more upfront work.

You can find the VSG60 SCPI manual in our SDK, linked below.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/

If you have additional questions let me know.

Andrew

[RSmith]

Hello,

Bit of background:
we are looking to replace our current automated test gear with signal hound equipment. These test systems are accessed over network and previously I have used the SCPI implementation with python to automate measurements remotely which has worked really well.

The question:
I need the VSG60A to stream IQ data for a custom waveform and the only way I can see so far of doing this is through the API. However I cant find if the API can connect remotely to the VSG60A pc over the network. Can the API do this?

Otherwise I will have to store code on each test system pc just to inject the IQ data. If I do this can I use the SCPI commands and the API at the same time? or will I need to rewrite the code to use the API only?

any suggestions would be much appreciated.

Thanks!

• This topic was modified 3 years, 11 months ago by RSmith.

[jjoonathan]

Disabling IF filter: If the only tradeoffs were gnarly rolloff and uncalibrated amplitude, sure, but antialiasing is a considerable foot-gun, especially for swept signals like mine. I would probably not opt to disable IF filters for my application. After all, I was able to obtain a stable trigger with the filter in place, it was just in an unexpected location. It might be useful for other purposes… but it’s definitely a foot-gun and not motivated by this particular application so I wouldn’t mind if you kept the option restricted to the API layer.

As for independently controlling FMT FFT size, I think that’s worth the effort to expose. In a perfect world, it would do its own FFTs for the purposes of the preview, but since FMT configuration already happens in a separate dialog, you could probably get away with hijacking the RBW setting while the dialog was open if that’s significantly easier. In any case, a slider akin to a multimeter “resolution / speed” tradeoff slider (but with frequency resolution / time resolution) would be an elegant way to expose this setting and intuitively communicate both the “50% overlap” architecture from the manual and the 512-16384/power-of-2 nuance that you’ve mentioned in this thread. Of course, once that tradeoff is communicated you’ll have people like me asking for time resolutions finer than 512/2 but every step forward is worthwhile even if they can’t all be made at once.

Cheers,
J

Attachments:

You must be logged in to view attached files.

[jjoonathan]

Thanks for the detailed answer! 512/2 sample trigger resolution is definitely better for this application than 1638/2 sample trigger resolution. I still want to toss in a vote for additional trigger capabilities that might drive that down towards 1 sample 🙂

You’re right that I’m inevitably going to need the API, but for one-off debugging and quick checks it’s nice to stay in the GUI.

Is there a way to control the FMT resolution independently of the spectrogram in Spike since it also uses Zero-Span>FFT Settings>RBW?

[Andrew]

jjoonathan,

You can change the FFT size used with FMT triggering by adjusting the RBW. If you change the RBW to 1MHz for example, a 1024pt FFT will be used (round up to the next power of 2).

You might need to adjust your FMT after you increase the RBW since the noise floor will increase.

The min/max FFT sizes that are actually used on the hardware are [512/16384]. Anything below or above those values will be clamped.

Hopefully this help improve the jitter enough to be usable.

You might already be aware, the API is available, and the 250MS/s I/Q captures are can be programmatically controlled through the “Segmented I/Q captures” API. We have several examples of this in the SDK. For your chirped signal, you could setup the video trigger level as you are in Spike, collect the data, and realign the trigger post acquisition. (basically run another video trigger in software). Justin mentions the video trigger limitations in your other thread.

We appreciate your feedback and detailed posts. It’s great to see the wideband captures being pushed to their limits!

https://signalhound.com/software/signal-hound-software-development-kit-sdk/

[Justin Crooks]

I can speak to the signal path portion. When your sample rate exceeds 61.44 MSPS, the video trigger moves from the API to the FPGA. It triggers on the amplitude of the raw 250 MSPS data, before the digital bandpass filter is applied. There is significant rolloff beyond the 160 MHz point, but triggering can still occur. The thought was if you are video triggering on a signal contained within the 160 MHz bandwidth, it would be transparent to the user, but energy just outside the 160 MHz bandwidth is the exception.

This was resolved in the SM200C, since we filter and resample more aggressively on the FPGA and trigger on the PC, but I realize this doesn’t help you.

Hysteresis: I would love to hear more about what you had in mind, and if you can give us a use case. More advanced triggering is something we have talked about and would like to explore. Obviously there are a lot more options at the API level than the FPGA level.

[Andrew]

Hi fgroger,

Unfortunately the VSG25 and VSG60 do not share drivers or codebases. This request is something I could add to our customer request log, but I don’t have any sort of timeline on when I could try to port the VSG25 to Linux. We have not done any work to ensure all drivers are available or that code could be easily ported to Linux. It was designed as a Windows only device.

As far as the SA44B on Linux, we are glad the Linux APIs are satisfactory for you. Just note, we have obsoleted our Linux APIs for the SA44B due to limitations between the drivers and how we handle USB transfers. We noted periodic data loss that cannot be avoided, detected in software, or recovered from in our current design. Something to keep a look out for moving forward.

Regards

[fgroger]

Would it be possible to add a linux .so file for the VSG25 to the SDK?
Since the VSG60 has already linux support, I assume it wouldn’t be that much effort.

We are currently using a SA44B for our factory test, which works fine with linux. We switched away from windows because of stability issues.
Now we want to replace our clunky signal generator with a TG44A (linux supported).
The VSG25 would be much better because of the ability to test modulated signals.

Regards

• This topic was modified 4 years, 3 months ago by fgroger.

[osy]

Dear Justin,
Thansk for your comment.
And can you give me any valuable option try in API or configurtion/setting to smoothnout? Even 6dB attenuator shows similar result even though it align a little bit.
(image rejection, reference level,…)
End customer push me to investiagte any resolutuion withoout sacrificing dymanic range.
Thanks,
SY

• This reply was modified 4 years, 3 months ago by osy.
• This reply was modified 4 years, 3 months ago by osy.

[twood]

Hi Andrew

Thanks for the prompt reply and the tip about older versions.

I’m using SCPI to remote control. I couldn’t get “SYST:IMAG:SAV xxx” to work so I’m using “SYST:IMAG:SAV:QUIC” instead. I’m not wild about QUIC because I can’t specify the folder to use but it seems to consistently use the last manual save folder, which is good enough.

I’m fine with the metadata and I think having it somewhere in the file would be great, I just want some control over its appearance.

If I could, I’d also like device temperature and voltage via SCPI. I gave up on trying to get this via calls to sa_api.dll intermingled with Spike invocations (Spike occasionally fails to find the device even though I’ve called saCloseDevice() a few seconds beforehand).

Terry

[Andrew]

tyang,

1) This will be difficult to measure. This number will include USB transfers, hardware acquisition speed, as well as buffering and processing latencies in the API. For certain modes like real-time, we only provide sweeps at specific intervals which means the latency for a specific event can be anything up to that interval. That being said, latencies are likely in the 16-100ms range depending on the measurement.

2) In your code I do not see a channel power measurement. Each call to saGetRealTimeFrame returns one sweep and one persistence frame (to create the persistence display). For your purposes you can ignore the frame and just focus on the sweep. You are indexing just a single value in the sweep. The channel power measurement in Spike is an integration over a portion of the sweep based on your settings. There will be additional math to calculate a channel power value on a sweep returned from the API.

We have a couple of resources that can help you get started. The equations for calculating it are in the blog post. I have also attached a file that contains some code snippets from Spike that calculate channel power. You will not be able to compile this code, but it will illustrate the operations involved and you should be able to write your own implementation using it.

https://signalhound.com/news/what-is-channel-power-and-occupied-bandwidth/

https://www.youtube.com/watch?v=V40PqIoMwhM&trk=organization-update-content_share-embed-video_share-article_title

Regards,
Andrew

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

Attachments:

You must be logged in to view attached files.

[Andrew]

Try setting the sweep time in the API to 1ms instead of 6 seconds. With 1ms the sweep time parameter will be effectively ignored and it will use the minimum sweep time needed to achieve the 1Hz RBW which will be 2-4 seconds depending on window function. If you set the sweep time to 1ms, this will mirror the settings used in Spike more accurately which it sounds like is working for you. Spike also uses the API, so if you are able to find settings that work in Spike you simply need to mirror them in the API to get similar results.

Regards

[hquezada]

Hello,

I apologize for the last post. I didn’t mean to post that incomplete.

I did try using a Nuttall window as you suggested and it did not make a difference unfortunately.

The PC I am using is Dell OptiPlex 9020.
Processor Core: i5
RAM: 16GB
CPU Freq: 3.30GHZx4
Available Memory: 257GB

I am able to reproduce it on Spike. The thing I don’t understand is that how on Spike, the settings I require are working fine without any lagging, but not with the API? I am consistently getting ~6sec sweeps on Spike as well.

I have noticed that immediately after replugging it, it is working correctly (6 sec sweeps) for about 1-3 times, and then that is when it is getting stuck.

Also, I know in the API the user is responsible for passing in the sweep time. The manual says it is recommended to use between 10ms-100ms, however would it be better to for my application to use 6 seconds?

What CPU specs would be required to have a rbw of 1Hz?

[Andrew]

hquezada,

You did not mention which RBW shape/window function you are using. I would recommend the Nutall window for this measurement. It will speed up the measurement by about 2x which will help with stability.

Based on the sweep time and warning you are receiving, it sounds like the PC is unable to keep up with the measurement. The measurement as configured will require high sustained USB throughput and high CPU usage to perform, more so than sweeps with larger RBWs, which is why you are seeing issues at this RBW and maybe not others.

The 250s sweep time tells me the API is likely falling behind and getting in an undesirable state. I have configured this sweep in Spike and get consistent ~6 second sweep times. Are you able to reproduce this in Spike?

What is the make/model/CPU of the PC you are using?

Regards

Attachments:

You must be logged in to view attached files.

Hello,

I am currently using the example API code for “simple sweep” for a Linux machine. The code works just fine with relatively large spans and rbws, however my project requires very low span and rbws values.

The problem I want to address is how to reduce the sweep time.

Specifically, the values I am passing into the code is as follows. The values were chosen from the same settings that were used in Spike to capture the data needed:

center frequency: 5GHz
span: 1000 Hz
ref level:-70
rbw: 1Hz
vbw: 1Hz
sweep time: 0.001 s

Here are the observations I have made:

1. When running the code with the specifications mentioned above, the code takes about 250 seconds to execute (however a few months ago I remember it taking around 10 seconds). Sometimes it takes about 10 seconds if the Preset function is added at before initialization, but after about 10-20 consecutive runs, the execution freezes. I have found that the function that is primarily responsible for taking this long is “bbFetchTrace_32f”.

2. The only error I get returned from any of the functions used is for “bbFetchTrace_32f” which is “Sweep uncalibrated. Data invalid or incomplete” which I traced back to the manual and saw it was “due to either USB data loss during device acquisition or being unable to keep up with the necessary processing to create the sweep”. However, even with this error, I am still getting all of the amplitudes from “max” array.

[Andrew]

There are provisions in our protocol for detecting this kind of data loss. They didn’t make it into the final product but could be added with a software update. Some of our other products drop connection as you describe, the VSG60 will actually drop connection if any issues occur with the DMA xfers, as exposed through the USB API.

The sandy bridge processor is relevant. When we were first developing the BB60A we did development on sandy bridge processors and were never able to get the device to run fast and stable, we found out this was likely due to the Renesas USB 3.0 controllers used during this generation of CPU. The 3rd generation Intel CPUs (Ivy Bridge) started shipping with Intel USB 3.0 controllers and this fixed our stability issues. There is lots of chatter from around that time online (2012) regarding these Renesas controllers. Many companies making high speed USB 3.0 equipment stated to avoid these controllers.

Our user manuals all specify a minimum of 3rd gen Intel processor specifically for that reason, so you have the “Native” Intel USB 3.0 controllers.

You could try installing a USB 3.0 card if possible, there are several that have been tested to work with our products. The startech one has two USB 3.0 controllers on it (one controller for 2 adjacent ports), so it can support two of our devices streaming at their maximum rates.

https://www.amazon.com/Inateck-Express-Controller-Internal-Connector/dp/B00JFR2H64/ref=sr_1_1?keywords=B00JFR2H64&qid=1582645060&sr=8-1

https://www.amazon.com/StarTech-com-Express-SuperSpeed-Dedicated-Channels/dp/B00HJZEA2S/ref=sr_1_1?keywords=B00HJZEA2S&qid=1582645115&sr=8-1

I released an update to the VSG60 software today that reduces the sample rate on the CW output. It might be enough to be stable on this machine.

Andrew

• This reply was modified 4 years, 6 months ago by Andrew.
• This reply was modified 4 years, 6 months ago by Andrew.
• This reply was modified 4 years, 6 months ago by Andrew.
• This reply was modified 4 years, 6 months ago by Andrew.
• This reply was modified 3 years, 1 month ago by Andrew.

[Andrew]

KE5FX,

Yea, you have the right idea. We don’t really specify an exact number of buffers in the API, but you could think of it as about 200 buffers. We chunk the data up into ~1ms chunks maximum and pipeline them. Internally it’s handled as a couple large circular buffers with arbitrary indexes into them. The USB DMA transfers control the flow of the data through the pipeline. Whenever the API blocks on submit I/Q, it’s because the API is waiting for the next DMA xfer to complete and free up more space in the pipeline.

As long as you are submitting I/Q data at a rate faster than your specified sample rate, the API will always have ~200ms of data to absorb any delays.

We chose the 1ms chunk/buffer size because the API needs to upsample and correct the I/Q data before being transferred, which usually means one or more FIR filters need to be run over the data. The small buffer size ensures data keeps moving through pipeline in a ‘continuous’ fashion but is still few enough buffers per second to keep delays associated with thread synchronization primitives to a negligible amount.

Let me know if you have more questions!
Andrew