Search Results for 'api'

[Andrew]

Roman,

The API is setup to only return UBX messages when GPS is locked and outputting NMEA sentences. This is a result of how we package and return this data. For this reason, yes, you would need to see GPS lock before expecting messages.

Is there an event that consistently leads to lost GPS lock? Is it after sending a message? Does your GPS antenna have access to clear sky? I can’t say that I have seen a scenario or heard from a customer that a reboot of the device was required to attain GPS lock. Is it possible one of the messages is configuring the device in an undesirable state?

We only have experience sending the NAV5 message for changing the platform model. That code example is in our SDK (you probably already found it). I have not used the cold boot command. If it forces the GPS to do a cold boot, this will take many minutes or longer to get GPS lock again, I’m assuming you are waiting an appropriate amount of time?

[Justin Crooks]

Jay,
Our Audio Demod tool in Spike would be able to give you the exact frequency of the audio pilot tone, but unfortunately it clamps to 20 kHz. In normal swept mode your accuracy will be limited to your RBW. Marker peak, delta, next peak would give you the audio frequency +/- your RBW. An RBW of 1 Hz would give you a 1 Hz accuracy. If this is not accurate enough, the next step would be to either put in a request for us to increase the maximum audio frequency in the Audio Demod mode, or use the API and do the FM demod yourself.
The peak deviation can be viewed in zero span mode FM, as you did. Measuring a local max, then a local min, with markers, should give you a peak-to-peak deviation.

• This reply was modified 1 year, 2 months ago by Justin Crooks.

[pooja.sagathiya]

Hi,
I am using a BB60C and its working well with the Spike SW. But when using the LabVIEW examples, I keep getting the “Device not open” error when running the vi. I re-loaded the bb_api-64.dll driver from the LabVIEW drivers download (and deleted the -64 text) and restarted by PC and got the vi to work once.Any help is appreciated. Thanks!!

[Andrew]

Hello rlisboa,

There is no current timeline on availability for this. You can follow updates here, https://signalhound.com/support/forums/topic/bb60c-api-for-arm/

I will be sure to update the linked thread when we do have something to share.

Currently the only ARM support we have is for the SP145 API, compiled on the NVidia Jetson (Orin AGX) platform.

Regards

When will there be API ARM support for the BB60?

[Andrew]

We have made one small step in this direction yesterday with the release of the SP145 API for the Nvidia Jetson AGX Orin platform. This is a highly requested pairing. It supports sweeps and I/Q streaming with some minor limitations. Hopefully some of you here or future visitors looking for ARM platform support can benefit from these efforts.

If you have any follow up questions or issues with the API, please reach out to me at aj@signalhound.com.

All of these files are now located in our SDK.

Thanks

[Andrew]

Hello,

This scenario is also unfortunately not something you are going to be able to make work with the capabilities of the BB60s. The video trigger is a function of software running on the PC, so it’s fully post acquisition and USB transfer. Any sort of trigger mechanism using the video trigger detection would have very poor resolution.

Additionally the BB60s are not really a good choice for generating a pulse. One of the ports can be configured as a logic high or low, but the resolution on this is very poor.

There might be an alternative way to accomplish this. If you have an external trigger source, such as a GPS PPS signal, that you could route that to both BB60s, the API will mark the position in I/Q stream where the external triggers occur and you could measure them relative to the video triggers you detect. A rather elaborate setup and some code to tie it together, but that should give you something like 40ns of resolution on the timing differences between 2 BB60s.

Our other devices, the SM and SP analyzers, have an internal GPS, which with a GPS antenna could be used to timestamp the data, which would also give you a relative timing between the 2 analyzers of ~40ns, essentially trading the need for an external trigger source with an external GPS antenna for each receiver. The timestamping is all done automatically, so the final code might be slightly simpler.

Let us know if you have follow up questions.

[RGedminas]

Justin,
Thank you for the response. I am once again trying to accomplish a similar task. I would like to have my bb60c and bb60d both in zero span with a video trigger setup in software. From there I would like each device to output a trigger pulse when the video trigger is triggered, from there I would like to use an oscilloscope to measure the delay between the two triggers. Is this possible with the API?

[Justin Crooks]

Steve,

You can communicate with the API without Spike running, but Spike is required for SCPI. There is a hidden mode if you don’t want it visible.

• This reply was modified 1 year, 8 months ago by Justin Crooks.
• This reply was modified 1 year, 8 months ago by Justin Crooks.

[Steve Barba]

In fact, we are using the API even though that limits us and is trickier to configure for our software automation. PyVisa & SCPI works smoothly on other devices. We’ll use a different company’s spectrum analyzer for future projects. Thanks for the information.

[Andrew]

Hi Steve,

If you want to use SCPI, then yes Spike has to be running. Spike has a hidden mode, which can be activated by launching it from the command line with a special flag. The Spike user manual details this.

If you want a true headless interface, you could use the API’s which are located in our SDK. The headless APIs support only basic data acquisition such as sweeps and I/Q data. Any additional processing or operations such as markers or channel power, or etc, would need to be performed in your application.

Let me know if you have follow up questions.

[Andrew]

Hi Wilson,

Yes, empirical tests have been done. A recent test showed a typical switch time at ~43ms.

It’s important to realize that it can depend on a few things. The 43ms above was done by repeatedly switching frequencies with no I/Q data acquisition at each frequency, probably the optimal scenario.

The switch time includes things like sending the stop streaming command to the device, flushing all USB transfers, cleaning up the large arrays allocated in the API, reconfiguring the instrument, and starting up the stream at the new frequency. Some of these are more deterministic than others.

The BB60 is rather slow in this regard. Both the SM200/435 and SP145 devices have something called the I/Q sweep list in the API. This allows you to preconfigure up front a list of frequencies and I/Q sample counts to collect, and execute this all at once. This brings switching time to sub-1ms at the cost of having to know in advance the frequencies you want to switch to.

The VSG60 is similar in that to get the full speed of 200us, you need to feed the switch frequencies far in advance to keep the queue saturated. If you don’t, the full switch time is more like 100ms.

You may contact me directly at aj@signalhound.com if you want to discuss any of these options in more depth.

Hello,

I am capturing I/Q data of varying frequencies via the BB60C API and need to switch center frequency using bbConfigureIQCenter(). My question is, how long does this configuration take?

For the VSG60A, a frequency switch configuration is listed in the manual as taking ~200 μs, however no mention of this is in the BB60C manual. Another thread on here estimates “10s of ms” for this switch, but is there any documentation or empirical tests done to measure this?

Regards,
Wilson

[BEged]

Hello Support Team,

We currently use BB_API Version 5.0.6 (6/22/2023), which provides a way to configure the device for IQ streaming by way of bbConfigureIQ. In our use case, the IQ stream we take out of the API has multiple consumers with differing needs, meaning that we already do our own filtering and decimation downstream, with multiple differing sets of parameters.

This in turn means that we take the lowest common denominator form of the stream out of the API, which happens to be the full 40MS/s stream without any decimation whatsoever. Our problem is that the API already does its own filtering and decimation, even in the case of the largest bandwidth setting, using valuable CPU resources that we would like to spend elsewhere.

This has us wondering whether you might consider extending the API such that it would allow taking out IQ streams without any preceding processing whatsoever. Something along the lines of bbConfigureIQRaw(int device).

We realize that this would affect the frequency domain structure of the stream (e.g. it might be a 80MS/s real sample stream instead, with a center frequency that is a complex function of other streaming parameters), but as we do our own processing downstream anyway, we could just absorb whatever we need to deal with that into those downstream processing tasks.

Regards,

• This topic was modified 1 year, 9 months ago by BEged. Reason: hello, regards

[Andrew]

Hi mlund,

Unfortunately no. If you are trying to configure either sweeps or an I/Q stream in the API, most of the settings in the Spike software control panels directly correspond to settings available in the API, but you have to write code to properly configure those desired settings. There is no notion of presets in the API.

It should also be known that the device itself stores very little of the configuration (most memory on device is volatile), almost all of the configuration is PC side.

Is there a way for Spike to create a setup file which I can then send to the device through the API?

I see in Spike the Preset option.
In the API I do not see a way to send a setup file to the device.

[Andrew]

Andy,

Unfortunately this is the only sample rate available from our API.

That being said, in MATLAB, you could use the resample(x,p,q) function like this,

> y = resample(x,9,10)

and y will be resampled to 437500, which would be a nice integer. Is this what you’re trying to do?

[Andrew]

Is the I/Q data 16-bit integer or are you using the 32-bit floating point data from the API? If you are using the 16-bit integer data, there is an additional scale factor you must account for.

Also, what value are you comparing it to in Spike? If you are looking at a modulated signal, you’re going to need to do a channel power measurement. If looking at a CW, then the instantaneous I/Q power will have more relevance.

dBm = 10*log10(i^2 + q^2) is the correct equation. Make sure it’s log10 not log2.

Look forward to your response.

I am using python to get data from BB60C, but I met some problems during unit conversion to mV from I/Q data .

In this reference https://signalhound.com/sigdownloads/SDK/online_docs/bb_api/index.html#IQDataTypes

It said dBm = 10log (I^2 + Q^2), I^2+Q^2 is P in mW, I tried AM_in_mV = (P_in_mW * 0.05)^0.5
But the result is not the same as in SPIKE. Where did I get wrong?

[Roger]

Hi ANguyen,

The value of SA_TG_SWEEP is 4 (source: API docs). Any value above that will trigger the invalid param error.

Definitions can be found in the API docs at the link above and/or in the source code.

– Roger