Search Results for 'api'

[joeqsmith]

STUPID STUPID STUPID… pointer problems… Must have been too late in the day and I could not see it.

I am reading the API document and I am trying to understand what I need to do to get the BB60C into zero-span mode.

Basically, I am wanting to try and decode that 2FSK signal I mentioned earlier using Labview. I have it now working with your demodulator using the clipboard copy paste. I also have it working with the raw IQ data now with the file save under zero-span. Next step is just to pull the data directly from the BB60C.

Also, I did not see anything in the API for triggers. Does this mean that the triggers in Spike were all at a higher level?

I am attempting to use the latest API and for the most part, everything seems to work which is why I wonder if I found a bug.

I did notice that when I call the bbGetDeviceType, it always returns a 0. The device is open when I make the call. It does not return an error.

I assume the problem is between the keyboard and chair but I noticed the document mentions four possible types including BB_DEVICE_BB124
but the header only defines three.
// Device type
#define BB_DEVICE_NONE 0
#define BB_DEVICE_BB60A 1
#define BB_DEVICE_BB60C 2

Is this call functional?

Thanks

[Andrew]

Hello ssw,

Did you download the API files found at this link?
https://signalhound.com/download/bbsa-application-programming-interface-for-windows-3264-bit/

In this download folder you will find two examples, simple_sweep_1 and simple_sweep_2. They will show you how to open, configure, and acquire data from the SA44B. You will use the saConfigCenterSpan function to control the frequency range of a sweep, and you will use the saGetSweep functions to acquire one sweep at your desired configuration. The example files should be able to be compiled and ran.

Hopefully this is enough to get you started. Contact us at support@signalhound.com if you have additional questions.

Regards,
A.J.

Hello! My name is SungWon and I am a hardware engineer.
I am using the SA44B for our product, and I have some questions. The software development environment is Visual Studio 2015 and I am working with C ++.

First, how to set the frequency band to measure. I have read the API manual, but since I am a hardware engineer, it is a bit difficult to understand.

Second, what is the API function that reads Amplitude? Or how can I know the Amplitude value directly?

I refer to the API manuals and examples, but it is hard to understand what they are. I have also used the forum, but it is hard to know because I only have to look at the example.

Thank you!

[Justin Crooks]

Ramin,
At this point we do not have a software interface to automate Spike’s EVM measurements, but it is something we have talked about, and may eventually add.
Right now, you’d have to choose between reading the Spike software EVM manually, or using the API to capture I/Q data and something like Matlab or LabView (or other library) to compute EVM.

Hi all,
I am designing an automated (production) test system for an ISM band 2.4GHz digital transceiver board. I need to measure EVM on a DQPSK modulated signal and was thinking of using BB60. I know that it is possible through Spike (at least one of marketing pictures is showing that). But is it possible trough API or any other way under control of a test software?

Regards
Ramin

[catalin_ro]

I might reply to this one!

First of all, the buffer length is in I/Q samples, not in 32-bit floating point values. So, the 16384 I/Q samples in each buffer actually means 32768 (2*16384) 32-bit floating point values. Considering that, the index that you reported in the example, 26666, is mostly correct.

But there is a well hidden problem in how you determined it. The API manual states that the trigger position is in I/Q samples number. So you must first convert the trigger position to the I/Q sample number before multiplying it by 2.

So you have SamplePos=TrigPos/DecimRatio (integer math!) and then go at 2*SamplePos in the received buffer to get the samples after the trigger.

The way you estimated the sample position is not correct because for many trigger position values, when using integer math, 2*Pos/Decim is different from 2*(Pos/Decim) and you end up accessing the Q1/I2 instead of I1/Q1 (the samples are considered I1/Q1, I2/Q2 etc.).

Catalin

[Andrew]

Hello Catalin,

It sounds like you found the source of the issue, which is that the API is not thread safe. In our software I always limit API function calls to one thread, so I can’t make any guarantees, but I believe each device could be interfaced in a different thread once open. The opening process itself is not thread safe, and you do not want to interact with one device from two different threads, for instance, don’t try to re-initiate a device from one thread when another thread is still retrieving IQ data.

The invalidDevice error that you are seeing would indicate corrupted memory and/or corrupted initialization sequence. My guess is that this is also related to thread safety. If you continue to see this issue, we might start considering corrupted internal flash memory/damaged traces/issues with microcontroller/etc.

rgds, You may contact me at the email in my previous reply if you wish, and are still experiencing issues.

Regards,
A.J.

[Andrew]

Hello sszqdz,

I apologize for the confusion. The bbFetchRaw function, before the last API version, returns trigger values relative to the full 40MS/s rate. To convert to values relative to the IQ data you received, simply divide the trigger values by the decimation rate, 64 in the example you provided. In the latest API version with the bbGetIQ function, we are performing the calculation for the user.

Regards,
A.J.

[catalin_ro]

I decided not to start another thread because the problem I have just discovered is related. The setup is 100% identical.

There is spurious trigger event occurring on the first ever call of bbInitiate with trigger input enabled, after opening the receiver, even if the trigger input is hardwired to ground. Subsequent bbInitiate calls do not cause spurious trigger events.

If the first ever bbInitiate call is with trigger input disabled there is no spurious event when later enabling the input.

The spurious event is always in the first ever received buffer at sample 572 with 64-bit APIs and at sample 1144 with 32-bit APIs. Tested with 32-bit and 64-bit API 3.0.11 (bbFetchRaw) and 64-bit API 3.0.14 (bbGetIQ).

Catalin

[catalin_ro]

More to my reply…

I have been able to get it running in my application as well. In the end, after playing around connecting/disconnecting the receivers, I got it going as expected.

But, in the process, I have also seen the undocumented bbDeviceInvalidErr error code for the second receiver. While all other error codes have pretty meaningful names, this error code isn’t even documented as possible result by the API manual.

More to that, while that happened, I decided to see if the second receiver could still be used by another application instance. So I released if from the application instance that gave me the error and I had no problems starting it in a different instance of the same application.

To better understand what the application does, simply think of a radio monitoring software that allows defining hand-off receivers for the detected transmissions. I can dynamically define/undefine the hand-off receivers and I only have issues starting them. By undefining the application, I can start separate application instances for them and they always work as expected.

Catalin

• This reply was modified 8 years, 11 months ago by catalin_ro.

[catalin_ro]

Hello Andrew,

Based on your reply, I have re-checked the API manual (completely re-reading the first pages!) and came across the multi-threading related comment. That paragraph states that the API functions calls are not thread-safe and that they must be protected in the application.

Briefly said, my application has a C++ class that wraps all the required API functionality and provides all the multi-threading protection for one receiver. bbGetIQ/bbFetchRaw (depending on the API version!) is called from another thread that does only that.

When using two receivers, all management functions are called from the main application thread and the IQ buffers retrieving is done in two independent threads, one for each receiver. Do I have to add complete protection around bbGetIQ/bbFetchRaw so they are not called from different threads for different receivers?

Regards,
Catalin

[Andrew]

Hello Catalin,

Check out your other thread for my response to the 2 streaming receiver question.

As for performance regressions. I am re-visiting this issue for a short time. As we have discussed in earlier emails, the bbGetIQ function adds a small amount of additional overhead. At this point I have only seen a marginal regression on one Win10 laptop in our office. All other PCs I have tested exhibit a non-observable CPU increase by switching to the bbGetIQ functionality. In the latest 3.0.14 API, the bbFetchRaw function is simply routed to the bbGetIQ function, and will incur the small overhead.

I will use the Win10 laptop as a test bed for some potential optimizations.

In the mean-time, as we previously discussed, you can continue to use the 3.0.11 API version and the bbFetchRaw functionality.

Regards,
A.J.

[subscr]

Hi catalin_ro,

I am facing the same issues too with the new API and BB60C in a multi-instrument configuration. The older API has been more well behaved.

Infact, we had almost placed an order for several pairs of BB60C for a similar requirement. But now I think it will be worthwhile to wait and see if “multiple BB60C on the same host” issue can be resolved by Signal Hound.

To me it looks like an minor API issue. I hope it is taken care of soon.

rgds

Hello,

With the APIs that came after v3.0.11 there is a serious performance hit in zero-span mode, especially when using two BB60C simultaneously (Spike used for both of them). The test PCs are roughly equivalent – i7-2600/16GB/Radeon HD6850 and i7-4710HQ/16GB/nVidia.

Spike 3.0.21 (with API 3.0.11) shows about 10% CPU usage per receiver (so 20% total CPU usage when using both of them) when not decimating (27MHz BW/40MHz sampling rate).

Starting with Spike 3.0.22 (API 3.0.12 and newer) shows about 15% CPU usage for the same settings, but the total CPU usage jumps to 60% when using both receivers. Those 60% are equally split between the two Spike instances.

The test PCs are running Windows 10 Home, 64-bit, fully updated, including the newest drivers.

Regards, Catalin

Hello,

While trying to use two BB60C in the same Windows application, in IQ streaming mode, only the samples from the first started device are received. bbInitiate returns no error code, but neither bbGetIQ nor bbFetchRaw return any data or any error code for the second started device.
The test was done using API versions 3.0.11 and 3.0.14.

The same test on Linux, with API version 3.0.11, has the same end result. Even worse, on Linux even if used in separate applications the second started BB60C returns no IQ samples.

Any chance to get this fixed?

Regards, Catalin

[Andrew]

Hello sszqdz,

If you are happy with version API 3.0.6, you can get this by installing version 3.0.11 of Spike from the link below.

https://signalhound.com/sigdownloads/Spike/Spike(x64)_3011.zip

Once installed you can find the API in the installation directory.
If you have a newer version of Spike installed, you will need to manually uninstall it before 3.0.11 will install.

Hope this helps,

Regards,
A.J.

Hello,everyone
I wrote a program which use bb_api.dll.
My program crashed when I use the bb_api.dll of v3.0.13/3.0.14,but it ran well with v3.0.5.
So I want old dll between 3.0.6 to 3.0.12 to test.
So …can you help me ? Thanks~

[Anonymous]

Hi Art!

The example in the folder you download has no problem.
The problem I met is I want to get IQ data.
There is no this example.
So we have to build the VI our self with the getIQ data API.
I already wrote it, but I think something wrong.
It crash all the time when the API getIQ was called.
Do you need my VI? I can send to you.

[Andrew]

Hello akarthikeyan,

I apologize, I don’t have much experience with ctypes or Python but I can try to help.

It doesn’t look like you are creating a proper array to pass to our API. This line right here

min = ct.c_double(swlen.value)

It looks like you are simply create a single double, whereas you need an array of doubles. (This is an educated guess on my part)

Also, if you are calling GetSweep, you do not need to call GetPartialSweep. Unless you have specific reason to, you will only need GetSweep. GetPartialSweep is a method for retrieving a very long sweep as it is updating. You should start with simply GetSweep for now until you need this functionality.

There might be others who can be of further assistance.

Regards,
A.J.