Search Results for 'api'

We generally operate our SM200C in frequency sweeping “normal mode” and set a start/stop frequency. We would like to now allow our users the ability to set the rbw and period as well. Looking at the API documentation, I am not 100% sure I understand the best way to present the options to the user (I am most interested in normal and fast mode right now). The documentation states “The sweep speed is primarily set by the user explicitly, except in a few cases.” What are those cases?

Also, it appears that a user can set one of three modes, or set to “fastest sweep speed.” But since sweep time is “not selectable when measuring at the fast sweep rate,” does that mean that the API ignores it if a user tries to set it? Or will it drop out of fast mode and go to normal in order to use the value?

Lastly, it looks like the SmSweepSpeed doesn’t even have a slow/narrow option in the sm_api.h document, just auto, normal, and fast. I am guessing that auto is the one that chooses the fastest sweep speed based on the setting chosen?

Hi,

I’m struggling to implement the I/Q streaming feature of the 200c using the API. I have 2 sm200c’s using the same input, same trigger, same wiring and wire length, and same configuration. I’ve implemented some code that writes the buffer for each device to I/Q files for me to compare and I’m not getting the same outputs. The starting pulse time for each device is different from each other and from each previous run, but more importantly, the noise floors aren’t the same. Spike playback will show one around -50dBm (which I understand to be normal from other threads) and the other could be as high as -20 dBm. They take turns on which one is high and low, and occasionally, neither one is.

Is there a dynamic latency between triggering and recording? Why might my pulse times and widths be different from run to run? What may cause power fluctuations with each pulse? Why would playback show a signal with a noise floor way about another with the same configuration/conditions?

Thanks in advance!

JV

[Andrew]

Jared,

1) As long as the DLL is loaded, if you have opened the device via the saOpenDevice function, you will not be able to open the device again until either, you close the device, or unload the DLL. We have seen some environments like Matlab/Labview keep the DLLs loaded until you restart the environment. One way customers have got around this is by closing all possible device handles before their script starts, this ensures any open devices from a previous run close. If you are interfacing a single device, the handle will always be 0, so you can just call saCloseDevice(0) at the beginning of your script and that should make it available again.

2) The Python libraries may not stay completely up to date with the C ones. You can just add the function to the python interface. I believe we have implemented this function for the BB and/or SM200 APIs, you could check the python interfaces for an example of how to do it.

Here is how it is done in the SMAPI, this is defined in the sm_api.py file alongside the other function definitions.

smGetDeviceList = smlib.smGetDeviceList
smGetDeviceList.argtypes = [
numpy.ctypeslib.ndpointer(c_int, ndim=1, flags=’C’),
POINTER(c_int)
]

I have two issues I am trying to resolve.

1) I am using the Spyder IDE through Anaconda. Lets say I wish to debug and step through the “sweep_plot.py” example. I often need to “cntr+c” or abort using the “stop Debugging” button after the device has been opened, but before it has been closed. After doing this, I cannot reconnect to the device unless I close the console window and/or unplug and re-plug the device. How might I make this a little more robust so that an error like this will automatically reset the device if I no longer have the device handle?

2) I noticed that the C API has a function call to get the S/N of the attached devices “saGetSerialNumberList”. Unfortunately, the Python API does not include this function call and I am not entirely sure how to implement it. I need to run multiple SA124B’s on a single computer and need to present an option for which one to open. How might I get this function to work?

Thanks,
Jared

[Andrew]

The API does not perform automatic calibration based on temperature drift. The user is responsible for this. You can perform this by reconfiguring the device (calling saInitiate). This will reconfigure the device for your measurement and update the temperature coefficients. If temperature drift is a concern, you would monitor the temperature returned from the API, and reconfigure the device once a measurable drift occurs. The Spike software does this when a 2C drift occurs.

Let us know if you have follow up questions.

[Andrew]

Yes, it sounds like your understanding is correct. If you know the time of a specific PPS, and you know what I/Q sample it occurs on (information that our API provides), you can extrapolate timing to any sample. The PPS will appear in the I/Q stream each second, so you can continually correct for any drift/error.

The main advantage of using the internal ublox-m8 is convenience. In a multi receiver setup such as yours, what approach you take will likely depend on your timing requirements and/or hardware limitations (i.e. can you run 10M/PPS to every receiver).

The ext trigger example I mentioned can be found in the SDK, in the sm_series/windows/examples/c++ folder. It only shows you how to call the functions, it does not simulate timestamping. Programming specific questions are best directed to me via email, or if you need a more elaborate example.

Andrew

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

[JHoy]

Hi,

Is there any documentation for the SA124B Python API? I can read the API directly in code, but documentation would be helpful.

When running the SA124B from the API, does it perform automatic calibrations based on thermal drift or run time automatically, or does the user need to command this to occur.

Is there a way initiate a calibration (Recal) or to check the calibration status (Perform Cal indicator) through the API? I don’t see functions for these.

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

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