Search Results for 'api'

Using the API I have found the temperature reading does not update when calling the sa_query_temperature( ) function after the device has been initialized using the sa_initiate( ) function.

The voltage reading using the sa_query_diagnostics( ) function returns the following error after the device has been initialized using the sa_initiate( ) function.

“Error -9: {‘error_string’: b’Cannot perform requested operation while the device is active’} in sa_query_diagnostics()”

Is there a way to fix this without closing the device? I need to monitor the temp to know when to apply a device calibration while the device is saving data.

Thank you.

[Andrew]

Ed,

Unfortunately, this specific measurement would not be possible remotely via programming. While our software does accept SCPI commands (that you could send from Labview or Python) for most functionality, the measurement as configured in the picture above (zero-span channel power) is one of the few that cannot be fully automated.

There are some alternatives,

If you knew exactly what WLAN protocol you were measuring and it was not MIMO, you could use our WLAN measurements to fully capture, demodulate, and report the channel power. All of this is available via SCPI programming. You can determine if your signal would be able to be measured under this measurement mode by browsing our WLAN feature document,
https://signalhound.com/content/tech-briefs/802-11b-a-n-ac-ax-wlan-modulation-analysis-in-spike/.

If you were comfortable processing I/Q data, you could use the direct device API to acquire I/Q data, and perform the triggering and channel power measurement yourself. The device APIs are provided in our SDK,
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
Our API is primarily C/C++, but we have several examples on how to call our API from Python or Labview.
https://signalhound.com/software/signal-hound-instrument-drivers-for-labview/

If you would like to discuss your specific measurement requirements in more depth, consider reaching out to me directly at aj@signalhound.com.

Andrew

[Andrew]

I have been unsuccessful reproducing the issue with the API. Can you potentially put together a short script that reproduces the problem on your end?

I’m also now considering that you are in fact seeing networked data loss, and that could be tied to your specific hardware configuration and/or software.

While I do see the issue in Spike, I only see it ~1 out of 20 or so reconfigures, and the sweep is not corrupted, which led me to believe it was an erroneous warning.

You also have my email if you wish to communicate via email. It is easier to share pictures and code via email moving forward.

Andrew

[Andrew]

The API picks the maximum sweep time that ensures all configuration is met. That includes RBW/VBW/sweeptime. Setting a small sweep time ensures the minimum sweep time is chosen based on RBW/VBW.

I would ignore the uncal warning flag for now if it’s being thrown on the first sweep. I suspect it’s being set erroneously. I was able to reproduce this using your settings. The uncal data flag usually indicates network data loss, I’m going to need to investigate further to determine why it’s returning this warning for this configuration.

Andrew

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

[Andrew]

Nick,

It’s possible the preamp is not being configured in HDSDR. We don’t actively maintain the HDSDR interface, but we do provide the source code (It should be in the HDSDR zip folder). You could open up the project and verify that indeed we are not setting the preamp through the API, and recompile it to add this functionality.

Andrew

Another random batch of values I used was able to get the SM200C to error out with smUncalData.

I am in FREQSWEEP mode with:
* Auto speed
* 900kHz – 6GHz start/stop
* 30kHz RBW
* 100ms period
* Nuttall window

My app seems to be setting up the device with these settings fine, but when I try to get an FFT sweep, this is the value I get in return after the very first smFinishSweep call. Any ideas? It seems like I can “ignore” it, but should I be worried?

Also, I am still a little confused on the sweepTime option for the smSetSweepCoupling API call. I am setting the start/stop and RBW, is it safe to just pick a super small sweepTime since the system will just pick the fastest time it can based on the RBW/VBW?

[jmatusiak]

I see the confusion. I am working in Linux, it doesn’t look like you offer both 32-bit AND 64-bit. I think you only offer a 64-bit version, right?
libsm_api.so.2.1.17: ELF 64-bit LSB shared object

[Andrew]

Thanks for the update.

You would have copied the 32-bit API from the x86 folder in our SDK. Also if your application is 32-bit, then you are using the 32-bit API.

Andrew

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

[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, 5 months 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, 5 months 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, 5 months 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, 7 months ago by Andrew.