Search Results for 'api'

[Andrew]

1) My guess is that 0 duration just means the event lasted for a single sweep, and 0 bandwidth means that only a single point in the sweep exceeded your threshold. Does that line up with what you are seeing?

2) Using the recorder in Spike means that you would only have to write code that parses those files and looks for events. Using the API gives you more flexibility to write files in a format that’s better for you, and also you can automate more of the recording process vs manually saving the files in Spike. It’s the same underlying data/samples in both approaches.

Our data rate is 160MB/s. Using the API you can choose whether to receive 16 or 32-bit complex values. The 16-bit are shorts, and 32-bit are floats.

Retrieving I/Q data via the API is by default continuous. If you set the purge flag to false, the I/Q data will be continuous. The API stores about 1/2 second worth of I/Q data internally, so you must not let this internal buffer “wrap/overflow/etc”, otherwise you will have a gap in samples. You must continually poll the API for the duration of time/samples you need. You can detect gaps by monitoring the sample loss parameter and the status flag returned from the bbGetIQ function. You can request arbitrarily large buffers sizes from the API if desired. If you plan on streaming for long periods of time, I suggest requesting buffer sizes around ~1/60th of a second. This is still a small enough buffer to quickly allocate and does not call into the API (which has a small amount of overhead) too many times per second.

Andrew

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

[JGeng]

Hello Andrew,

Thanks for all the reply. I’ve tested those solutions you suggested, and have some following questions :

1. In interference hunting mode, I can collect event with 0 duration and 0 bandwidth. I’m guessing the 0 duration is due to rounding or truncating, but what does 0 bandwidth means and what is the precision for duration and bandwidth?

2. I would like to capture all small duration event so it seems capturing IQ and do post processing is what I should do. What’s the difference between using IQ recorder and write my own code with API?

For IQ recorder : I still need to verify it’s correctness since a 40M/s sample rate has rate 150.94 MB/s so that means there’s still a loss(theoretically should be 160MB/s)?
And also, the api shows that the IQ data is stored in 32 float but the IQ recorder is recording 16 bits(and normally the recording device in the past is storing in 16 bits so I’m a little confused)

For API : I’ve tested to acquire by using bbGetIQ() function, what is the mechanism for BB60C to update the buffer? I call the function several times and it actually get all the data from the buffer out. How do I get the next data without making a gap? Do you suggest anyone that can answer the question for bb_API?

Many thanks.
Jing

[Andrew]

Hi Jing,

The interference hunting mode is not a real-time measurement, it operates using standard sweeps. This means for short duration events like the ones you are measuring, you can miss them. Increasing the RBW can help improve sweep time.

If all of your events are within a 27MHz span, you can use our real-time measurement mode to be able to visualize all events in the frequency domain, and use our sweep recorder to capture these events. The data format for the sweep recording is different than the recorded data in interference hunting mode, but all events that have 2ms duration will be visible.

You can also record events in zero-span using the I/Q recorder in zero-span mode. You can set up a video trigger and capture a sequence of I/Q time domain files that should contain a significantly higher percentage of the events than you capture in interference hunting mode. Depending on how the pulses arrive, it may not capture 100% of them.

Another option is to use the API in I/Q streaming or real-time mode to capture data and programmatically store the events of interest.

Andrew

[Andrew]

Tuong,

The I/Q recorder in Spike is not open source. That being said, we could look into extracting some useful code from the recorder as an example for customers to use. I will consider what this would look like.

We have a much older open source recording utility that was written for the BB60A/C many years ago. It illustrates multi-threaded recording of full IF/IQ data. It will likely not compile against our current APIs, but it might be helpful for you.

https://signalhound.com/sigdownloads/BB60C/BB60_Demos.zip

Andrew

Want to call the APIs using an ARM-based device.
Hence like to compile the libraries to execute in an environment based on AArch64.
Request you to share the supporting libraries if Feasible.

[Andrew]

When you stop and exit the software are you calling smCloseDevice or smAbort? If not it’s possible the device is still active. If you stop and exist the LED should have gone back to solid green. Flashing indicates data transfer.

I’m not aware of any outstanding issues that prevent the instrument from going between different modes like this. The API can only operate in one measurement mode at a time.

If you had two instances of your software running, this could certainly create this type of issue (let’s say your previous instance of your software didn’t fully close and is still running in the back ground) Our API does not stop you from interfacing the device from two different processes (which is not recommended or supported).

Are you monitoring the status’s returned from the API. When you mention getting garbage data, is it possible you are simply not getting any data and the API is throwing an error? (maybe you are just looking at uninitialized memory?)

If you continue to have issues after further investigations you can contact us directly at support@signalhound.com. You could also create a small sample application that illustrates the problem and we can try to reproduce it on our end.

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 4 years, 1 month 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 4 years, 2 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 4 years, 2 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 4 years, 2 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 4 years, 2 months ago by Andrew.