Search Results for 'api'

[Andrew]

Try setting the sweep time in the API to 1ms instead of 6 seconds. With 1ms the sweep time parameter will be effectively ignored and it will use the minimum sweep time needed to achieve the 1Hz RBW which will be 2-4 seconds depending on window function. If you set the sweep time to 1ms, this will mirror the settings used in Spike more accurately which it sounds like is working for you. Spike also uses the API, so if you are able to find settings that work in Spike you simply need to mirror them in the API to get similar results.

Regards

[hquezada]

Hello,

I apologize for the last post. I didn’t mean to post that incomplete.

I did try using a Nuttall window as you suggested and it did not make a difference unfortunately.

The PC I am using is Dell OptiPlex 9020.
Processor Core: i5
RAM: 16GB
CPU Freq: 3.30GHZx4
Available Memory: 257GB

I am able to reproduce it on Spike. The thing I don’t understand is that how on Spike, the settings I require are working fine without any lagging, but not with the API? I am consistently getting ~6sec sweeps on Spike as well.

I have noticed that immediately after replugging it, it is working correctly (6 sec sweeps) for about 1-3 times, and then that is when it is getting stuck.

Also, I know in the API the user is responsible for passing in the sweep time. The manual says it is recommended to use between 10ms-100ms, however would it be better to for my application to use 6 seconds?

What CPU specs would be required to have a rbw of 1Hz?

[Andrew]

hquezada,

You did not mention which RBW shape/window function you are using. I would recommend the Nutall window for this measurement. It will speed up the measurement by about 2x which will help with stability.

Based on the sweep time and warning you are receiving, it sounds like the PC is unable to keep up with the measurement. The measurement as configured will require high sustained USB throughput and high CPU usage to perform, more so than sweeps with larger RBWs, which is why you are seeing issues at this RBW and maybe not others.

The 250s sweep time tells me the API is likely falling behind and getting in an undesirable state. I have configured this sweep in Spike and get consistent ~6 second sweep times. Are you able to reproduce this in Spike?

What is the make/model/CPU of the PC you are using?

Regards

Attachments:

You must be logged in to view attached files.

Hello,

I am currently using the example API code for “simple sweep” for a Linux machine. The code works just fine with relatively large spans and rbws, however my project requires very low span and rbws values.

The problem I want to address is how to reduce the sweep time.

Specifically, the values I am passing into the code is as follows. The values were chosen from the same settings that were used in Spike to capture the data needed:

center frequency: 5GHz
span: 1000 Hz
ref level:-70
rbw: 1Hz
vbw: 1Hz
sweep time: 0.001 s

Here are the observations I have made:

1. When running the code with the specifications mentioned above, the code takes about 250 seconds to execute (however a few months ago I remember it taking around 10 seconds). Sometimes it takes about 10 seconds if the Preset function is added at before initialization, but after about 10-20 consecutive runs, the execution freezes. I have found that the function that is primarily responsible for taking this long is “bbFetchTrace_32f”.

2. The only error I get returned from any of the functions used is for “bbFetchTrace_32f” which is “Sweep uncalibrated. Data invalid or incomplete” which I traced back to the manual and saw it was “due to either USB data loss during device acquisition or being unable to keep up with the necessary processing to create the sweep”. However, even with this error, I am still getting all of the amplitudes from “max” array.

[Andrew]

There are provisions in our protocol for detecting this kind of data loss. They didn’t make it into the final product but could be added with a software update. Some of our other products drop connection as you describe, the VSG60 will actually drop connection if any issues occur with the DMA xfers, as exposed through the USB API.

The sandy bridge processor is relevant. When we were first developing the BB60A we did development on sandy bridge processors and were never able to get the device to run fast and stable, we found out this was likely due to the Renesas USB 3.0 controllers used during this generation of CPU. The 3rd generation Intel CPUs (Ivy Bridge) started shipping with Intel USB 3.0 controllers and this fixed our stability issues. There is lots of chatter from around that time online (2012) regarding these Renesas controllers. Many companies making high speed USB 3.0 equipment stated to avoid these controllers.

Our user manuals all specify a minimum of 3rd gen Intel processor specifically for that reason, so you have the “Native” Intel USB 3.0 controllers.

You could try installing a USB 3.0 card if possible, there are several that have been tested to work with our products. The startech one has two USB 3.0 controllers on it (one controller for 2 adjacent ports), so it can support two of our devices streaming at their maximum rates.

https://www.amazon.com/Inateck-Express-Controller-Internal-Connector/dp/B00JFR2H64/ref=sr_1_1?keywords=B00JFR2H64&qid=1582645060&sr=8-1

https://www.amazon.com/StarTech-com-Express-SuperSpeed-Dedicated-Channels/dp/B00HJZEA2S/ref=sr_1_1?keywords=B00HJZEA2S&qid=1582645115&sr=8-1

I released an update to the VSG60 software today that reduces the sample rate on the CW output. It might be enough to be stable on this machine.

Andrew

• This reply was modified 4 years, 10 months ago by Andrew.
• This reply was modified 4 years, 10 months ago by Andrew.
• This reply was modified 4 years, 10 months ago by Andrew.
• This reply was modified 4 years, 10 months ago by Andrew.
• This reply was modified 3 years, 6 months ago by Andrew.

[Andrew]

KE5FX,

Yea, you have the right idea. We don’t really specify an exact number of buffers in the API, but you could think of it as about 200 buffers. We chunk the data up into ~1ms chunks maximum and pipeline them. Internally it’s handled as a couple large circular buffers with arbitrary indexes into them. The USB DMA transfers control the flow of the data through the pipeline. Whenever the API blocks on submit I/Q, it’s because the API is waiting for the next DMA xfer to complete and free up more space in the pipeline.

As long as you are submitting I/Q data at a rate faster than your specified sample rate, the API will always have ~200ms of data to absorb any delays.

We chose the 1ms chunk/buffer size because the API needs to upsample and correct the I/Q data before being transferred, which usually means one or more FIR filters need to be run over the data. The small buffer size ensures data keeps moving through pipeline in a ‘continuous’ fashion but is still few enough buffers per second to keep delays associated with thread synchronization primitives to a negligible amount.

Let me know if you have more questions!
Andrew

I was curious about how the streaming mechanism works on the VSG60A. The API manual doesn’t go into much detail on the streaming model, but it does say, “If the buffer is full and vsgSubmitIQ() is called, the function blocks until space is available in the buffer.”

I assume there are really two (or more) buffers, such that the first two calls to vsgSubmitIQ() will run without blocking. Subsequent calls would then block until at least one buffer becomes available, allowing the app to refill that buffer while the other one is still playing — correct?

Otherwise, if there’s only one stream buffer, is it still possible to support seamless streaming of arbitrary amounts of baseband data from the host?

[rpettingill]

Like I said, API usage won’t be possible on an embedded device with no OS.

As a future feature request, maybe create an abstracted packet protocol that allows low level interfacing, and all your proprietary chip configurations can be handled internally? Just something to consider to reach more customers.

[Andrew]

rpettingill,

No the Spike software is not capable of measuring phase noise on a pulsed signal. There is no synchronization mechanism built in to software to synchronize to a pulse. Additionally, the measurement duration can be > 1 second depending on what phase noise offsets are selected. You wouldn’t be able to get much resolution on a 5us pulse.

If possible, I would recommend using a CW output on your transmitter, or you would need to roll your own phase noise measurement using our API or trying to capture the pulse in zero-span and post-processing the captured I/Q waveform.

Regards,
Andrew

[Justin Crooks]

The protocol to simply configure a center frequency contains commands to directly set registers on about a dozen different chips, writes values to FIR filters to optimize IF flatness and image rejection at the frequency selected, and digital tuners to center the frequency of the I/Q data. The API handles all of this behind the scenes.

[Andrew]

So, you would want to set purge to false. Purge tells the API to throw away any accumulated data in the API, which would include your waveform and trigger location. Once you set purge to false, you will also need to poll the API until you see the trigger position.

Regards

[Andrew]

Are you setting purge to true in that example? Effectively flushing any data and triggers that have accumulated?

I see only one GetIQData function call. The BB60C is a streaming device, so how much data do you have accumulated before the actual trigger occurs? Are you sure the trigger isn’t buffered in the API and you just haven’t polled it yet through the getIQ function?

The BB60C API only stores about 1/2 second of I/Q data. If this buffer fills, it will be forced to wrap it’s internal circular buffer. If it takes you 1/2 second to call getIQ after configuring you might have discarded that I/Q data.

Ideally, you would be polling the BB60C in another thread and waiting for the trigger to occur or transmitting the VSG60 waveform and trigger in another thread while you poll the BB60C in your main thread. That way there is no worries about any I/Q accumulation buffers overflowing. If your VSG60 waveform is short, that is probably not the case here, but worth noting.

[jgauthier]

Andrew,

Still not seeing triggers. Could it be the order I’m executing things?

bbConfigureIO(int32(0), int32(64))

bbConfigureIQCenter(CenterFreq)

bbConfigureIQ(downsample, bandwidth)

vsgSetFrequency(CenterFreq)

bbConfigureIQCenter(CenterFreq)

bbInitiate(uint32(4), uint32(0))

vsgSubmitTrigger()

vsgSubmitIQ(iqPtr, count)

vsgFlushAndWait()

GetIQData(iqCount, purge)

I tried switching the order of vsgFlushAndWait and GetIQData, but it makes no difference.

In GetIQData, I have:

function [status, iqArray] = GetIQData(handle, iqCount, purge)
    nullPtr = int32(0); 
    purgeArg = int32(purge);

    iqArrayPtr = libpointer('singlePtr', zeros(iqCount*2, 1));
    iqCountInt = int32(iqCount);

    triggerPtr = libpointer('int32Ptr', ones(4,1)); % pointer to array of 32-bit integers
    triggerCount = int32(4); % size of the trigger array (32-bit int)

    status = calllib('bb_api','bbGetIQUnpacked',handle,...
            iqArrayPtr,iqCountInt,triggerPtr,triggerCount,...
            purgeArg,nullPtr,nullPtr,nullPtr,nullPtr);
    calllib('vsg_api', 'vsgFlushAndWait', handle);
    fprintf('Triggers:\n');
    triggers = triggerPtr.Value;
    disp(triggers);
    % Convert results to complex numbers
    iqArray = reshape(iqArrayPtr.Value, 2, iqCount);
    iqArray = iqArray(1,:) + 1i * iqArray(2,:);
    iqArray = transpose(iqArray);
end % of GetIQData

And I still find no triggers – disp(triggers) shows:

Triggers:
   0
   0
   0
   0

Any hints?

Thanks,
JonG

[Andrew]

Dhivagar,

Please check your email, as I have responded to these questions through email.

I am copying my email response below.

The “export as CSV” feature in Spike will only export the data that is visible on the Spike display. Spike can only display up to 4 million points at a time. The recording feature can record much longer durations of I/Q than the “export as CSV” feature. If you need recording longer than 4 million points, you will need to use the recording feature in zero-span mode or use the API and program a custom recording solution. You cannot record longer than this using the CSV feature in Spike.

The data that is stored in the CSV files when using the “export as CSV” feature, is I/Q values. Each line of the file is one I/Q value separated by a comma. Each I/Q pair is separated by a newline. Each I/Q value is scaled to mW. To convert to power (dBm) use the equation 10*log10(i^2*q^2).

You can learn about the I/Q file format when using the Record I/Q feature in zero-span by looking at the Spike user manual on page 77. https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf
The I/Q data store in the recording file is stored as full scale 16-bit complex integers.

If you want to convert the I/Q recording to a CSV file, you will need to write a program to parse the binary file. You can do this in any programming language or environment such as MATLAB if you have access to such. We do not provide any such conversion utilities.

Regards

SA44B is working fine with SCPI commands. But, I am facing some issues in span settings.

I want to check the frequencies with a 2GHz span.

When set to 2GHz span, peak tracking is not proper & suddenly the application is closing.

With a 100MHz span, it is working fine. But with 100 MHz, i need to change that parameter for every 100MHz and have to run the application.

So I want to set wider span or is there any API to move the peak to the center?

Can anyone suggest me a solution for this problem?

[Andrew]

jgauthier,

80% is a good number to use across the board. I will say, there is a trick you can use to ensure you are always getting the maximum available bandwidth. If you simply set the bandwidth equal to the sample rate (100%), then after you configure the receiver you can call the bbQueryStreamInfo function, and it will report the bandwidth that was actually used by the API. It will internally clamp to the upper bound for each given decimation.

The maximum bandwidth for any given decimation was calculated by looking at the decimation filters available at each decimation stage and making a decision about what cutoff frequency is going to give us the performance we need at that given rate.

Regards,
Andrew

For the bbConfigureIQ function, how is the Maximum Bandwidth column on page 22 of the BB60 API manual calculated? Are these approximated? Some are exactly 0.8 * SampleRate, others are a bit more. I realize they’re maximums, and I can specify narrower filtering…

I’m just trying to decide if I should just use that 80% across the board as a max bandwidth, or populate a table using a 14×2 array and choose a particular decimation/MaxBW pair…

[Andrew]

Hi jraymond,

I have heard reports of this as well. We haven’t used or compiled the HDSDR project in a few years. I believe some customers have got this working by recompiling the project against the latest BB60C API. There have been hardware changes since our last HDSDR release such that the newer APIs are needed to interface BB60Cs. You could try dropping in the latest BB60C API to see if that works.

I’m not sure when we will swing back to this project. Maybe some other customers here could make some recommendations.

Regards,
Andrew

[Andrew]

Jon,

Here is some code to get this going.

First, you will want to ensure you configure the external port to accept a rising edge (or falling) external trigger.

calllib('bb_api', 'bbConfigureIO', handle, int32(0), int32(64));

The best time to call this would be right after opening the device and only once. The 64 is taken from the header, it is the value for BB_PORT2_IN_TRIGGER_RISING_EDGE (0x40).

Then you will want to create a trigger array and count just like the iq data.

% Trigger parameters
triggerptr = libpointer('int32Ptr', zeros(4, 1));
triggercount = int32(4);

In this instance I am creating an array of 4 integers to store trigger positions. If I am only expecting 1 trigger, then an array of one will work fine.

Now I need to call bbGetIQ with these new parameters.

status = calllib('bb_api', 'bbGetIQUnpacked', handle, ...
         iqarrayptr, iqcountint, triggerptr, triggercount, purgearg, ...
         nullptr, nullptr, nullptr, nullptr);

And pull out the array when it returns

triggers = triggerptr.Value;

If a trigger occurred during this capture of I/Q, you will see it in the trigger array.

disp(triggers);

Might show

230722
        0
        0
        0

Meaning an external trigger event occurred at sample index 230722 (zero-based).

Regards,
Andrew

• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.

[jgauthier]

Back at it after a week’s vacation…

I realized I was calling libpointer with the wrong parameters, so I changed it to:

triggerCount = int32(70); % size of the trigger array (32-bit int)
                                  % from SDK example "iq_external_trigger.cpp"
        triggerArray = 0:0:triggerCount; % array where we'll store trigger events...
        triggers = libpointer('int32', triggerArray); % pointer to array of 32-bit ints
...
status = calllib('bb_api','bbGetIQUnpacked',handle,iqarrayptr,iqcountint,triggers,triggerCount,purgearg,nullptr,nullptr,nullptr,nullptr);

I still get an error, but it’s

Parameter must be scalar.

Error in libpointer (line 21)
 ptr=lib.pointer(varargin{:});

Error in bbgetiq (line 67)
        triggers = libpointer('int32', triggerArray); % pointer to array of 32-bit ints

Are there any working examples of calling that C-library function from MATLAB? I’m stumped.