Search Results for 'api'

dear signal hound,
I need the API version 3.0.5 to run my old MATLAB code.
how can I find that?
best regards.

[Andrew]

You will likely be able to make an RF connection to the antenna but none of our software supports it. You will need to use the provided software or API that is available on the product page to control the antenna.

Please note, we have not evaluated this antenna and cannot provide guidance in building a direction finding system using it.

Hi there!

Can we connect directly BB60C & IsoLOG 3D DF antenna aaronia without any API interface.
What is the uses of the BB60C in there.
Please advise me.

[Justin Crooks]

Michael,
I suppose if you had a 2-channel oscilloscope, and used the API, you could stream data out of both with embedded triggers, use the scope (programmatically using SCPI) to calculate the time delta, and then add or skip the appropriate number of samples on one channel. You’d want an external 10 MHz reference to tie them together as well.

It’d be a bit of a project… a 2-channel VSG or SDR would be a more straightforward answer.

[Andrew]

Michael,

There is not a direct one-to-one analogue to zero-span in the API. Zero-span is implemented in Spike with the I/Q streaming capabilities in the API. The I/Q data is then converted to all the plots (AM/FM/spectrum/waterfall/etc). There are examples of capturing I/Q data in the SDK. Conversion routines from I/Q to AM or spectrum are available online or made easy in environments like MATLAB.

Let us know if you have follow up questions.

Andrew

How do I setup the BB60 in zero-span mode through the API?
Do I set the span to “0” in bbConfigureCenterSpan?

Thanks
Michael

[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 4 years, 3 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, 7 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, 7 months ago by osy.
• This reply was modified 4 years, 7 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, 8 months ago by Andrew.

Attachments:

You must be logged in to view attached files.