Search Results for 'api'

[Andrew]

If you can run a GPS antenna to the unit, you can get the API to performing timing for you. Enabling the smSetGPSTimebaseUpdate() allows the internal GPS to discipline the timebase of the unit. While the device is open, you can query the state of the lock with the smGetGPSState() function, you can wait for ‘disciplined’. Once disciplined the timestamps you received from the smGetIQ() function are referenced to the GPS. Technically you can get timestamps without the disciplining, but you will see timestamp drift between PPS’s.

If you want to do this manually with an external 10MHz and PPS, tell the instrument to use an ext 10MHz timebase with the smSetReference() function and connect the PPS to the trigger input port (and the 10MHz reference to the 10MHz ref input). Then when streaming I/Q, the PPS events will show up in the trigger output buffer. Its then easy to timestamp samples based on their location relative to the PPS trigger position in the stream. With this method though, you will have to acquire and parse the NMEA data from the GPS to know the absolute time of the PPS event. The advantage of doing this externally is being able to use higher accuracy GPS receivers than our internal one, and running multiple units off of one external GPS which will have better precision for certain tasks.

We have an example for the first method discussed above, but not for the second. We only have a generic ext trigger example which you can view to see how the triggers come in. Hopefully the explanation is enough to piece the rest together. If you have follow up questions as you work through this, please let me know.

Spectrums via the API sweep configuration are timestamped when using the internal GPS, but due to how we process the sweeps, it will be hard to get precise timing on an event in the sweep. It should really only be used as a coarse monotonically increasing timer. The I/Q sweep list functionality in the API allows you to sweep the I/Q acquisition with the same speed as our fast sweeps. Timestamping with the I/Q sweep lists only works with the internal GPS (rather than providing an ext 10M/PPS), but this approach would give you precise timestamped ‘steps’ of I/Q samples. The downside, is that you would have to FFT and construct the sweep if you wanted the classic sweep plot as well.

You can email me directly at aj@signalhound.com if needed.

Andrew

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

I am a new user investigating ways to utilize the SA124B for long term propagation analysis. Before I completely write it off, I would like to ask if:

1) Does the SA124B have support in GNU radio?
2) Does the SA124B have API support for the Raspberry Pi (version 3 or 4)? I believe I read that the API was not designed on run on an Arm processor.

If these are possible, could someone please point me to the proper resources to get these to work?

Thanks,
Jared

[Andrew]

The 32-bit floating point I/Q data has the corrections applied. It is scaled to dBm. You can read more about this in the API manual in the I/Q data types section. If you are doing an FFT on the I/Q data, ensure your are normalizing your window function and properly scaling the output of your FFT. You should be able to simply do a log power conversion of the FFT results to get dBm.

Andrew

[Andrew]

jyaron,

Yes, triggering for any I/Q acquisition other than the SM200B/SM435B 250MS/s I/Q capture mode needs to be performed in the customers application. There are no current plans for any firmware updates to the SM200C to enable this functionality on device. The SM200C does not have the 2 second I/Q acquisition mode that the SM200B does, it only supports full 200MS/s (with decimation) streaming. It uses the internal memory for buffering to support full streaming operation.

MATLAB did struggle to even maintain full 200MS/s rates in our testing, so I agree that performing triggering directly in MATLAB at the 200MS/s rate might be difficult. Consider building a small C++ wrapper around our API that performs the triggering that you can call into from MATLAB.

I will add this idea to our customer wish list. It would be interesting to add a triggering interface for customers who do not need streaming I/Q but would like a triggered capture instead.

I appreciate the feedback.

Andrew

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

[jyaron]

“This was resolved in the SM200C, since we filter and resample more aggressively on the FPGA and trigger on the PC…”

Is this why the MATLAB API support file SMIQReceiver.m (for the SM200C) does not offer any support for triggered captures using video, ext or FMT (like SM200BWidebandIQ.m)?

Is triggering expected to be performed by MATLAB code? Since not sure this processing horsepower is possible.

Is it safe to assume that the SM200B is likely a better choice if the most robust MATLAB support is desired?

Are there any plans for an SM200C FW/API update to support optional triggering features similar to SM200BWidebandIQ.m so that extensive MATLAB trigger processing during streaming is not required?

Also, does the SM200C have internal 2sec capture memory (like the SM200B)… allowing for support of future native SM200C based triggered capture features?

Thanks.

• This reply was modified 3 years, 7 months ago by jyaron.

[Andrew]

Thanks for the feedback Cyprien.

While not exactly API support, there is already SCPI automation support for the LTE measurements. You could write a script to automate the measurement and pull measurement information from Spike. Full blown API support isn’t on the roadmap right now. Look in the SDK for the SCPI manual and examples.

Development on the BB60D is still moving forward. Dynamic range and phase noise have improved quite a bit, both contributing to better LTE measurements.

If you have any additional feedback on the LTE measurements, please reach out to aj at signalhound dot com.

Thanks

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

[Cyprien]

I was a little surprised when I noticed the casual comment in the latest Spike release “* Added LTE measurement mode.”!

I have been playing already and am very impressed especially the cell scanner – just what I was hoping for to upgrade a monitoring station solution. Now I am really looking forward to the BB60D to make things smoke from a dynamics perspective. In a dream world API support would be utterly awesome!

Absolutely amazing work!

Dear Signal Hound,
Referring to the API manual, “The Video bandwidth is implemented as a simple rectangular window, averaging the amplitude readings for each frequency bin over several overlapping FFTs”, I wonder what are the differences between averaging methods used in Acquisition panel of Spike application and VBW filtering.
However, I searched through the comments and found out that API uses an IIR filter to implement the VBW filter. Generally speaking, How can I understand mathematics behind of VBW that it can get continuous values.
best regards

[Andrew]

Hi Stanley,

The Quasi-peak detector is currently only available in Spike. We don’t have any way to automate this measurement via an API at this time. If we provide anything in the future it would probably be through SCPI commands to Spike. We don’t have any plans to pursue this at the moment though.

I appreciate your feedback, if you would like to reach out to me via email at aj at signalhound dot com, I can contact you if we ever pursue this in the future.

Andrew

Hello,
One one of my critical mission is to support Qpk on our application – EMI Spectrum Analyzer adopting BB60C. I cannot see Qpk related command in API manual even though I see Qpk on Spike.
1) Any update on plan to support Qpk on API?
2) Can I have technical documents or any material to implement Qpk utilizing existing APIs on the manual as external customer?

Thanks,
Stanley

[Justin Crooks]

We ran a fresh batch of tests, with the API as it currently stands. I was a little surprised. A 2 GHz span (roughly 2 ms of actual sweep time), took from start to finish (not queued), on average:
SM200B = 4.4 ms
SM200C = 4.8 ms
There were no significant peaks in the 1000-sweep test. From this, it looks like the SM200C has a bit higher latency across the board (something like 2.8 ms vs 2.4 ms).
Obviously these numbers will vary from computer to computer and sweep to sweep, and peak numbers will vary based on CPU load, but it’s a starting point.

• This reply was modified 3 years, 10 months ago by Justin Crooks.
• This reply was modified 3 years, 10 months ago by Justin Crooks.

[Andrew]

The self-cal function in the BB60 API is for the BB60A only and has no effect on the BB60C.

Andrew

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

[lsullivan]

thank you for your answer, But I am referring to self-calibration part that has been written in the API manual.
regards.

[Andrew]

GSingh,

You could use PyVISA to control the VSG60 software using SCPI commands. You can read about our SCPI commands and see some examples in the SDK.

If you are using the API directly to control the instrument, you will need to generate your own complex I/Q waveform to output to the device. For a multi-tone signal, you could sum your complex sines/tones into an I/Q buffer to transmit. Just ensure that you scale the final result so that the peak magnitude of any given sample doesn’t exceed 1.0, and ideally, select a final buffer size that allows all of your complex sines to phase wrap nicely.

Unfortunately we don’t have any Python sample code for doing this. There are probably RF/DSP libraries that make it easy to generate complex sine waves with a given frequency.

Let us know if you have follow up questions.

Andrew

Hello,

which Real-Time processing algorithm do you use in your API? there is a block diagram of RF part in the BB60c user manual but there is no block diagram or document about signal processing in the API.

Do you have any signal processing block diagram like the way you have for RF chain in the user manual? I appreciate if you could give me a reference to understand how the API works for signal processing parts. To be honest, I’m using BB60c API in MATLAB and I need to know what is happening in API for Real-Time and Sweep mode.

best regards.

[Andrew]

lsullivan,

What is the nature of your question? Do you have a specific application in mind, or is there an issue you are having with the I/Q data?

Our API accounts for all filter delays and scaling factors. The size of the filter will primarily only affect the filter transition bandwidth.

Andrew

[lsullivan]

Dear signal hound,
which filtering algorithm you use in your API in zero-span mode? (design method, response type, filter order, frequency specification, magnitude specification, …)
best regards.

• This topic was modified 4 years ago by lsullivan.

dear signal hound,
In the API of BB60c, which kind of filter is used? IIR or FIR, please name the kind of filter you using.
best regards.

Dear signal hound,
which FFT algorithm you use in your API (BB60)?
best regards.

[Andrew]

Version 3.0.5 was released in 2015, and unfortunately we don’t maintain releases from that far back. Additionally, if you have newer BB60C hardware, version 3.0.5 may not support it. The API interface has not changed much since then. If you have the header file from the old project built against 3.0.5, compare it to the newer version found in the SDK.

Regards