Search Results for 'api'

[jmatusiak]

OK, I think I see my issue. When I initialized my device, I was setting the vbw to be what the rbw was. I then changed the rbw and kicked things off. The vbw wasn’t getting updated, so when I set the SweepCoupling to use the new rbw (200kHz now), but had the old vbw (100kHz), it caused the allocation error.

Dumb question, How do I know if I am using the 32b API or not? I haven’t seen this distinction anywhere.

[Andrew]

The allocation error indicates we failed to allocate memory at some point during the configuration. Usually the result of malloc failing. You can see this more often when using the 32-bit version of the API since memory allocation limit is lower.

Is it possible you were passing 200Hz instead of 200kHz as the RBW, or something similar?

Are you using the 32-bit API? If yes, is it possible your own allocated memory was high enough that our API couldn’t stay within the 32-bit limitations?

That being said, its certainly possible this is a bug and a specific combination of settings produces this error code. If you can provide a simple code example that reproduces the problem including information about your OS and what API version you are using, I can try to reproduce it. I was unable to reproduce the issue just based on the information you provided.

Andrew

• This reply was modified 3 years ago by Andrew.

[jmatusiak]

While playing with the SM200C sweep parameter values, I am trying to learn how to make sure that I can keep a user from doing something stupid.

I was randomly jamming in values and trying to make things break and was able to consistently do it with the following parameters:
start freq: 2.3GHz
stop freq: 2.7GHz
rbw/vbw: 200kHz
period 100ms

When I attempted to kick things off, I get an error of -13 (smAllocationErr). I guess I am confused as why that would be. I can go from 900kHz – 6GHz with 100kHz rbw/vbw with no issues.

So why is the above setup an “allocation” problem? In my mind I assumed that that meant the SH couldn’t gather enough resources, but that setup should be orders of magnitude easier. I can only imagine that I am misinterpreting something, but the API documents don’t go into a lot of detail for what the error means or for limits that I might be hitting with my params.

If I change the rbw to 100kHz, it works fine (which should take twice as much resources, hence why I am guessing I don’t understand the error).

• This topic was modified 3 years ago by jmatusiak.

[jmatusiak]

OK, I will go with Nuttall for now until someone on our end complains to me about it. Is the Nuttall window the one that caps out with a minimum of 30kHz for RBW (it wasn’t clear to me in the API document)?

[jmatusiak]

Thank you for the quick response. We were only going to give the user options for start/stop frequency, rbw, and period. Based on that, I think the best thing to do is to follow your recommendation and leave the speed as “auto” and let the user’s parameters drive the speed.

Do you have a recommendation for a safe window type since I am not going to give the user the ability to set it? I see you use flat-top in your example sweep app, but Nuttall in your thz sweep (btw, you spelled Nuttal with only a single ‘t’ in the API). I am leaning towards Nuttal, but I figured I would double check.

This seem like a reasonable set of API calls?

smSetSweepSpeed(this_device, smSweepSpeedAuto);
smSetSweepStartStop(this_device, this_startFrequency, this_stopFrequency);
smSetSweepCoupling(this_device, this_rbw, this_rbw, this_period);
smSetSweepDetector(this_device, smDetectorAverage, smVideoPower);
smSetSweepScale(this_device, smScaleLog);
smSetSweepWindow(this_device, smWindowNutall);
smSetSweepSpurReject(this_device, smFalse);
smSetAttenuator(this_device, -1/*auto*/);
smSetPreselector(this_device, smFalse);
smSetReference(this_device, smReferenceUseExternal);
shStatus = smConfigure(this_device, smModeSweeping);

Thanks again

[Andrew]

Yes, the sweep speed is by default set to auto and will choose the fastest sweep speed based on your configuration. I would leave it in this configuration unless you have explicit need to achieve some probability of intercept offered by the fast sweep speed. If you choose a narrow span, the API will override your selection and perform the “slow”/narrow sweeps regardless. That span cutoff is 5MHz. Slow sweep speed is not selectable otherwise.

If you choose fast sweep speed, VBW must equal RBW and your lower limit on RBW is 30/60kHz depending on window function selected. If your settings meet these restrictions we will automatically choose fast sweep speed when auto is selected.

I hope this clarifies.

Andrew

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

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 3 years, 2 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 3 years, 2 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 3 years, 2 months ago by Andrew.
• This reply was modified 3 years, 2 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, 3 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, 3 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, 3 months ago by Andrew.
• This reply was modified 3 years, 3 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!