Search Results for 'api'

[joeqsmith]

Andrew, I swapped the board out for the second one. It too has been solid. Not a single glitch and I am using the hub and extension cable as well. The BB60C has been in use a fair amount. It seems the Dell’s USB ports may just not be as clean. I guess you could buy the same PC and see if you could replicate the problem. Maybe there would be a way to allow the BB60C to auto recover. Attached my latest video with Labview. Things are a little cleaner and I have a much better understanding how to use the API now.

https://www.youtube.com/watch?v=Mkec-Eyhg7c

[joeqsmith]

No problem. I’ve continued to work with the API using LabVIEW. The more I use it, I like it.

Morning,

Thanks for the great products you are producing!

I’m looking for a way to start Spike from a batch file that will either:

1) Allow me to set the parameters of the spectrum analyser from the command line OR
2) Allow me to start spike with a saved Preset

I’m able to do this using the APIs and a custom program, but in some instances I would like to use the latest Spike functionality.

I’m running a remote pc with an SA44b connected and using tightvnc to connect to it, hence the need to start spike with some predefined parameters.

Many thanks for your help.

Regards
Jason

[Andrew]

Hello magintd,

I can clarify. The bbr file is a flat recording of sweeps only (frequency domain ‘bins’). The IQ data is not recorded in this file. The sweeps are stored as min/max arrays. If the avg detector is enabled, min/max should equal the same values. I will attach a basic bbr parser so you can see the layout and how we parse the files in our software.

If you are looking to get IQ data, then we do have another recording feature in zero-span that records IQ data. If you are looking for the ultimate flexibility, you could grab IQ data directly from the device with our APIs.

Let me know if you have additional questions.

Regards,
A.J.

Attachments:

You must be logged in to view attached files.

[Andrew]

Hi Joe,

Did you get download the latest API files from the link I posted above? The bbFetchRaw function is deprecated and is not used in any of the examples I provide. The function that replaces it is the bbGetIQ function and has more flexibility.

That said, decimation is the only way to control the sample rate of the device. bbFetchRaw will always return the same amount of data per call. You do not need to call bbQueryStreamInfo more than once. bbGetIQ allows you to retrieve an arbitrary amount of samples per function call. bbFetchRaw guarantees no loss of samples assuming data retrieval keeps up with the sample rate of the device. The API will store about 3/4 of a second worth of data before data loss occurs.

This information and more can be found in the API manual at
https://signalhound.com/sigdownloads/BB60C/BB60-API-Manual.pdf

Regards,
A.J.

[Andrew]

Hi Joe,

Glad you found your problem with that function.

Regarding getting IQ data from the receiver, take a look in the examples folder. There will be an example of the minimal IQ acquisition setup. This should be a good starting point. If you don’t see the examples folder, get the latest API files from this download

https://signalhound.com/download/bbsa-application-programming-interface-for-windows-3264-bit/

Video triggering occurs in the Spike software. The implementation is simply looking for the transition across a certain amplitude. (for() loop through each IQ sample). Pattern triggering is much more involved and is performed in the Spike software as well.

Regards,
A.J.

[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 9 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