Cannot capture all the event through spike software

Hello,

I bought a BB60C for interference hunting. The problem is that we’re not able to “hunt” lots of event.
What I’ve tested is that we connect a signal generator to the bb60C and create signal at 2.42GHz every 40ms with 2ms duration(pulse period 40ms, and pulse width 2ms). However it can only capture about 20% event. I’ve already set the span to 5MHz(much smaller than the real-time bandwidth 27MHz) and set a higher RBW to decrease the sweep time.

I’m guessing it’s the spike software processing limitation or delay since I see every event in time domain from spike. Or if there’s other limitation from the device? Or if I have the wrong settings?

Thanks,
Jing

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

Hi Andrew,

Thanks for replying. So in the interference hunting mode, it only capture one snapshot per sweep time?(Or there’s still some other processing time after each sweep) If that’s the case, how do we know the sweep time?(Or how do we know what’s the gap for missing event. For now it seems that it miss a lot of them)

Another question is that did the FFT process done in software or in the BB60C device internally?

Thanks,
Jing

The FFT processing is done in software. There is processing time associated with each sweep and there is blind time between sweeps where events can be missed. This is a general shortcoming of swept based spectrum analysis, and if your goal to capture 100% of short duration events, measurements like real-time and I/Q streaming are required.

Andrew

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]

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

Hi Andrew,

Thanks for the reply. That’s more clear for me. So if I use the IQ recorder, it will set to 16 bits for IQ data for default, and I have to do the transform and correction(based on the documentation) :

1. The correction value can only be acquired through API or there’s a table for finding it? I’ve tested that it seems only relate to the the reference level set, is that correct?

2. I’m always confused about what is the unit for acquired raw data(there’s different setting in api) for either IQ recorder or bbGetIQ api? Is is the voltage or power? mV or dbm or else?

Thanks,
Jing

1) When using the I/Q recorder the scale factor is not recoverable, so you will have to use the data as full scale if saving as 16-bit ints. If using the API you can store the scaling factor separately and use it to convert to dBm if needed. The reference level being used as the scale factor does not apply with the I/Q recording utility.

2) Check out the docs for more information on scaling, we use this approach for both our BB and SM line of receivers. I/Q values have a similar scale as a voltage, but need additional conversion if you want to use them as a voltage.
https://signalhound.com/sigdownloads/SDK/online_docs/bb_api/index.html#IQDataTypes

Andrew

[Author]

Posts