Search Results for 'api'

[Andrew]

Hi Kaiser,

It sounds like most of your assumptions about the API are correct regarding timings/etc.

FinishSweep returns when the data has returned and that data has been processed. One of the issues here is that the API will batch several operations/transfers together when we can, and in the event of queued sweeps, if you queue up several small sweeps, it might collect and process all these sweeps at the “same time” as seen by the PC (all the data is returned from the FPGA in the same transfer). So the FinishSweep might return and all the sweeps might already be done. It’s not until you get to wider span sweeps where FinishSweep could return when the next sweep has only just started.

I think the only way to guarantee some action occurs between two sweeps (at a software level) is to start/finish 1 sweep at a time.

If you can operate in a 40MHz bandwidth, using I/Q streaming with external triggers into the device to help sync would be a good way to go.

The software interrupts are an interesting idea, but I do think they would suffer from the same issue, where USB commands and data xfers would be batched together at times and it would be impossible to insert a software interrupt between two very small sweeps since they would occur back to back all on the FPGA. (FFTs for ‘fast sweep mode’ occur on the FPGA, so once the data is xferred back to the PC it doesn’t undergo any extensive processing.)

The GPIO sweeping mechanism (changing the GPIO on frequency crossings) was designed with this type of problem in mind and it sounds like you have already evaluated this feature.

Would an external trigger indicating a sweep is starting/ending be of interest? It’s not something we can do right now, but maybe we could consider it for a future update.

Regards,
Andrew

The SM200A is working great so far for me. Right now I’m looking into the best way to synchronize external actions with seeps.

For example, right now I queue up 12 sweeps, and start them with sm_api.smStartSweep(handle,i) and then continuously read them with

SmStatus status = sm_api.smFinishSweep(handle, queuePos, null,sweepsMax[j], ref sweeptimeEpoch[j]);

sm_api.smStartSweep(handle, queuePos);

I would like to synchronize some external events with start/stop of these queued sweeps. So, I guess my question is, is finish sweep basically the end of the sweep with minimum latency?

Based upon what I’ve seen, I have ~0.1ms for the LO to get back in position to start the next sweep. I’d like to issue a notice to some equipment before the next sweep starts. Is FinishSweep a good spot to do that, or is there some other synchronization that I can do? I know that I can twiddle GPIO ports, but my output is happening on the same system that’s working with the SignalHound.

I could also connect GPS, get time counts on sweeps, and run an external synchronization thread that looks at when the sweeps are executed, and send the commands at appropriate sweep intervals, but I’m concerned about >0.1ms deviation from system clock synchronization to SM200A GPS clock, and how to keep locked. If there was a way to query the SM200A clock, then I could likely synchronize also, but then even on Linux you’re getting into minimum system timeslice concerns, but interrupts could probably be generated to get good alignment.

It would be a lot easier if smFinishSweep is basically immediately returned post sweep, but my guess is that it returns once the data is present, which is a bit after the sweep, and thus not suitable to inter-process synchronization.

[kaiser]

I don’t see the post I made yesterday up here, so here I go again.

As I said before, I decided to get an SM200A and see how that works. The queuing up of sweeps is huge and really this device is much faster.

Right now I’m scanning 100MHz at ~0.3ms, which is great. Theoretically it could go as fast as 0.1ms (1THz/s sweep rate). I expect that a lot of the increase in time is sweeping the LO back to the beginning of the spectrum? I’m not sure.

Either way, I’m pretty happy with the SM200A and it’s performance.
The capture is a bit noisier, which will require me to add some smoothing or similar to my algorithms, but it’s not a huge deal.
Overall, if I could eek out a bit more performance (faster scans), that would be great. Here’s some prototype code I was using to test it below; any thoughts?

Again, great device!

// Configure the receiver sweep functionality
// Things to note for THz sweep speeds
// smSweepSpeedFast must be set
// RBW must equal VBW and be above 30kHz for Nuttall window
sm_api.smSetSweepSpeed(handle, SmSweepSpeed.smSweepSpeedFast);
sm_api.smSetRefLevel(handle, -20.0); // -20dBm reference level
sm_api.smSetSweepCenterSpan(handle, 2.45e9, 1.0e8);

sm_api.smSetSweepCoupling(handle, 100.0e3, 100.0e3, 0.001); // 100kHz rbw/vbw
sm_api.smSetSweepDetector(handle, SmDetector.smDetectorAverage, SmVideoUnits.smVideoPower); // min/max power detector
sm_api.smSetSweepScale(handle,SmScale.smScaleLog); // return sweep in dBm
sm_api.smSetSweepWindow(handle,SmWindowType.smWindowNutall);
sm_api.smSetSweepSpurReject(handle,SmBool.smFalse); // No software spur reject in fast sweep
sm_api.smSetPreselector(handle, SmBool.smFalse); // No preselector in fast sweep

// Initialize the device for sweep measurement mode
SmStatus status = sm_api.smConfigure(handle,SmMode.smModeSweeping);
double actualRBW = 0, actualVBW = 0, actualStartFreq = 0, binSize = 0;
int sweepLength = 0;
sm_api.smGetSweepParameters(handle, ref actualRBW, ref actualVBW, ref actualStartFreq, ref binSize, ref sweepLength);

float[] sweepMax, sweepMin;
sweepMax = new float[sweepLength];
float[][] sweepsMax = new float[1000][];
float[][] sweepsMin = new float[1000][];
for (int i = 0; i < 1000; i++)
{
sweepsMax[i] = new float[sweepLength];
sweepsMin[i] = new float[sweepLength];
}
sweepMin = new float[sweepLength];

long[] sweeptimeEpoch = new long[1000];

//the API allows us to queue up to 16 sweeps. They recommend queueing ~4 sweeps
//but we’re pretty narrow sweeps, so let’s try 12 to start…
// Start all sweeps in queue
int sweepsToQueue = 16;
for (int i = 0; i < sweepsToQueue; i++)
{
sm_api.smStartSweep(handle, i);
}
int j = 0;
int queuePos = 0;
while (j < 1000)
{
SmStatus status = sm_api.smFinishSweep(handle, queuePos, null,sweepsMax[j], ref sweeptimeEpoch[j]);

// Process/store sweep here
// Sweep in contained in the ‘sweep’ array

// Start it back up
sm_api.smStartSweep(handle, queuePos);

// Increase and wrap our queue pos
queuePos++;
if (queuePos >= sweepsToQueue)
{
queuePos = 0;
}

j++;
}

[catalin_ro]

If “shared clock” implies getting the clock from one BB60C to the other BB60C, some special API functions must be called in order for the API to use the same reference clock frequency. The 10MHz built into the BB60C is not quite 10MHz, but slightly off. When set to external reference, the API considers exactly 10MHz.

The end result of this issue is a tuned frequency mismatch and slight sampling rate difference.

[catalin_ro]

I’m using twin BB60Cs in something similar. And I’ve been through the same issues roughly two years ago.

(1) If you pass reference clock from one receiver to the other you need to properly set the reference clock frequency in both. When you will get proper time alignment you will see the drift. Discuss with Andrew about the special, kind of “dangerous”, API calls for properly setting the timebase information.

(2) Use IQ streaming instead of sweeping.

(3) Use an external trigger! A simple controller that can issue the sync pulses whenever you need and then align the samples in software. But be aware that there is a 4 samples pulse position imprecision at widest streaming bandwidth, as far as I recall. In my case the upper level algorithm automatically compensates it.

[Andrew]

Spike does additional processing per sweep that could be slowing it down a bit. You should measure the sweep times using the API for an accurate number to see if it would be adequate for your application. The BB60C doesn’t have any sweep queuing mechanism, so you incur the over head of processing and USB latencies for each sweep. 6-7 ms is probably the ball park for the fastest possible times.

We don’t have an SM200A demo/loaner program. If you are outside the US, your distributor might have a loaner program.

Regards

I’m trying to capture spectrum from two BB60C’s at exactly the same time, and having some issues.

The two references are locked; one set to output external reference, and the other set to receive an external reference. Good there.

Then I tried just kicking them off at the same time, via something like this, hoping that it would essentially :

` while (j < 1000)
{

Thread FirstSH = new Thread(delegate () {
var status = bb_api.bbFetchTrace_32f(DeviceHandles[0], unchecked((int)traceLen), sweepsMin[j], sweepsMax[j]);
});
Thread SecondSH = new Thread(delegate () {
var status = bb_api.bbFetchTrace_32f(DeviceHandles[1], unchecked((int)traceLen), sweepsMin2[j], sweepsMax2[j]);
});
FirstSH.Start();
SecondSH.Start();

FirstSH.Join();
SecondSH.Join();
j++;
}`

They start at basically the same time, but I can tell that they aren’t. How? Well, I’m essentially trying to measure a signal’s characteristics in two polarizations. So one BB60C on one polarization, and the other on the second. The signal is a TDMA signal (think standard Wifi), and often times one BB60 will see the signal, but the other won’t or have a partial capture, or whatever. So it’s not super-synchronized, which is causing havoc for my measurements.

So, I hook up a waveform generator (btw, feature request; make the trig/sync port be an in/out like the reference for synzhronizing sweeping of units. That would eliminate my need for the waveform generator).

But, the API doesn’t allow me to trigger a sweep from an external trigger (just in zero-span and some other modes). Or at least I can’t find a way for it to let me.

It looks like I could maybe set it to stream, and that would work…but I need to cover ~100MHz on each, and the simple spectral display is all I need.

Maybe I could stream IQ, and then tyr to time-align the trigger buffers between the two? Would that work well for getting me a simple spectral plot?

Anyone have any ideas? Is allowing triggers something that could be added to a mode in an upcoming release?

Thanks!

Hello

In previously API returned frame consist values from 0 to 1.
Values close to one meant constant pixel activity and I transformed frame values to colors to have spectrum histogram.
But in new API function bbFetchRealTimeFrame got another one parametr alphaFrame and I, as was shown in the example, ignored this parameter by setting it to 0. But in frame values I found values much less than one(even on the noise track) and my image frame became one-color.
Is this a bug in the new implementation?
Can you give pseudocode using frame and alphaframe to get the image?

Thank you

[Andrew]

Hello Andrew,

You are correct in noting that the ADC overflow is not tied to the IQ samples. We would need to do a bit of work to make that happen.

Right now, the ADC overflow flag is a boolean that is cleared once per call to GetIQ. Setting purge to true will not clear it right now.

Until we change the behavior of the API, it might be appropriate to ignore the ADC overflow flag when you want to purge IQ?

I apologize for the inconvenience. I will make a note of this issue and in the future maybe we can improve the reporting of the ADC overflow flag.

Regards,
Andrew

[Andrew]

Mike,

Yes I think I know what’s happening.

The MATLAB example folder includes the bb_api.dll which is outdated. If you have a newer BB60C only the latest versions of the API will be able to be used. (The older API version can’t recognize your newer BB60C) In that same SDK, go to the core API folder and copy over the newest API.

I’m assuming you are running 64 bit MATLAB so I think you just need to copy over the 64-bit API and header, overwriting what is already in the MATLAB folder. Copy the contents from
signal_hound_sdk\device_apis\bb_series\win\lib\x64
into the MATLAB folder with these existing files.

I look forward to your results.

Regards,
Andrew

We just received our BB60C. It is recognized by Spike and seems to be working OK with that software. However, our objective is to use the unit for automated measurements under Matlab, so we also installed the SDK and have been trying to use the Matlab examples. In Matlab, whenever the bbOpenDevice() function is called, we get only “Error opening device”. We are using Matlab 2018a under Windows 10. Do you have any suggestions as to what might be wrong? Since the BB60C works with Spike, I have to assume that we have some sort of software or software configuration problem.
Thanks!
Mike

Hello,

When using the latest API version (the 11/06/18 release). I am getting the error “access violation at address 0x0000000000000000” when using the DIRECT_RF or STREAM_IF flags. I am testing these options by modifying the example python code, and the only change that I am making is this flag.

Can I get some guidance as to how to get this working?

Best,

Nolan Luckett

[Andrew]

Ray,

Some other ideas,

1) Are you using a 32-bit OS? Our Linux APIs are compatible only for 64-bit OS’s.
2) Maybe try getting rid of all the soft links? Rename the main library to libbb_api.so and see if that resolves the issue.

Regards

[Andrew]

Hi Bittware,

I don’t have a timeframe for when SCPI support for zero-span would occur. I’m assuming triggering is an important aspect of your measurement? If so, then using the API directly to request IQ, trigger, and then FFT the IQ data to create the spectrum plot is the only alternative. Otherwise if you do not need triggering, then using SCPI with standard sweep mode seems like it would be adequate.

If you haven’t seen the APIs yet, you can find them on the SDK landing page.
https://signalhound.com/software/signal-hound-software-development-kit-sdk/

Regards,
Andrew

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

[Andrew]

Andrew4010,

Yes, APIs with version 4.0.0 and greater support all BB60C/A devices. We don’t maintain download links for older versions of the APIs. I don’t believe the interface has changed between 3.1.1 and the current version so it should be a drop in replacement.

Regards,
Andrew

Hello

Q1 I have old device.Is the API >= 4.0.0 backward compatible?
Q2 Where can I download BB_API Version 3.1.1?

Thank you

[ray62202]

I installed a fresh copy of Ubuntu LTS (downloaded ISO image yesterday from Ubuntu) for testing, so it is ‘factory new’.
Yeah, that linker message was so vague as to be useless (typical).

The only other thing I had to do was to install g++ in the standard manner – $sudo apt install g++.
I listed the details of the compiler config in the forum post.

I deleted everything and extracted the SDK from a new download, and captured the installation sequence below:

dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$ ldconfig -v -n .
.:
libbb_api.so.4 -> libbb_api.so.4.0.2 (changed)
libftd2xx.so -> libftd2xx.so
dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$ ln -sf libbb_api.so.4 libbb_api.so
dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$ sudo cp libbb_api.* /usr/local/lib
[sudo] password for dunn874:

This is the (SDK) library after the install, with libbb_api.so and libbb_api.so.4 as a soft links.

dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$ ls -la
total 14836
drwxr-xr-x 2 dunn874 riocdev 4096 Nov 1 10:49 .
drwxr-xr-x 5 dunn874 riocdev 4096 Oct 18 08:53 ..
lrwxrwxrwx 1 dunn874 riocdev 14 Nov 1 10:49 libbb_api.so -> libbb_api.so.4
lrwxrwxrwx 1 dunn874 riocdev 18 Nov 1 10:49 libbb_api.so.4 -> libbb_api.so.4.0.2
-rw-r–r– 1 dunn874 riocdev 14957792 Oct 17 16:21 libbb_api.so.4.0.2
dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$

This is the /usr/local/lib after the install
NOTE! the soft-link libbb_api.so is NO LONGER A LINK, BUT A COPY OF THE FILE

dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$ ls -la /usr/local/lib
total 43840
drwxr-xr-x 4 root root 4096 Nov 1 10:50 .
drwxr-xr-x 10 root root 4096 Jul 17 06:23 ..
-rw-r–r– 1 root root 14957792 Nov 1 10:50 libbb_api.so
-rw-r–r– 1 root root 14957792 Nov 1 10:50 libbb_api.so.4
-rw-r–r– 1 root root 14957792 Nov 1 10:50 libbb_api.so.4.0.2
drwxrwsr-x 4 root staff 4096 Jul 17 06:46 python2.7
drwxrwsr-x 3 root staff 4096 Jul 17 06:24 python3.6
dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/lib/Ubuntu 18.04$

Build the device_info project:

dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/sample_projects/device_info$ make
g++ -Wall main.cpp -o dev_info -Wl,-rpath /usr/local/lib -lbb_api

/usr/bin/ld: out of memory allocating 30374008975618 bytes after a total of 282624 bytes
collect2: error: ld returned 1 exit status
Makefile:6: recipe for target ‘all’ failed
make: *** [all] Error 1
dunn874@WE31900:~/Projects/signal_hound_sdk/device_apis/bb_series/linux/sample_projects/device_info$

Same problems

Please advise asap, we are on a tight schedule for a demonstration.

– Ray

I have been getting an error building the linux sample code:
Linker Error for sample project – device_info
…signal_hound_sdk_10_25_18/device_apis/bb_series/linux/sample_projects/device_info

I installed the .so library per BB instructions:
…signal_hound_sdk_10_25_18/device_apis/bb_series/linux/lib/Ubuntu 18.04/libbb_api.so.4.0.2

The build stops with a linker error:
g++ -Wall main.cpp -o dev_info -Wl,-rpath /usr/local/lib -lbb_api

/usr/bin/ld: out of memory allocating 30374008975618 bytes after a total of 282624 bytes
collect2: error: ld returned 1 exit status
Makefile:6: recipe for target ‘all’ failed
make: *** [all] Error 1

I have tried building on Linux Mint 19 (from Ubuntu 18.04) and on a real Ubuntu 18.04 LTE installation with the same results.

What am I missing? Any suggestions on what to check, since I assume your sample programs build an work fine.

– Ray

Linux info

>cat /proc/version
Linux version 4.15.0-38-generic (buildd@lcy01-amd64-023) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018

>uname -a
Linux WE31900 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v –with-pkgversion=’Ubuntu 7.3.0-27ubuntu1~18.04′ –with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs –enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ –prefix=/usr –with-gcc-major-version-only –program-suffix=-7 –program-prefix=x86_64-linux-gnu- –enable-shared –enable-linker-build-id –libexecdir=/usr/lib –without-included-gettext –enable-threads=posix –libdir=/usr/lib –enable-nls –with-sysroot=/ –enable-clocale=gnu –enable-libstdcxx-debug –enable-libstdcxx-time=yes –with-default-libstdcxx-abi=new –enable-gnu-unique-object –disable-vtable-verify –enable-libmpx –enable-plugin –enable-default-pie –with-system-zlib –with-target-system-zlib –enable-objc-gc=auto –enable-multiarch –disable-werror –with-arch-32=i686 –with-abi=m64 –with-multilib-list=m32,m64,mx32 –enable-multilib –with-tune=generic –enable-offload-targets=nvptx-none –without-cuda-driver –enable-checking=release –build=x86_64-linux-gnu –host=x86_64-linux-gnu –target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

[Andrew]

Hello Sri,

Our device APIs are standard Windows DLLs. The interface is exposed through a set of C functions, which means you can call these functions from most programming languages like Python, C++, Matlab, etc. Each language will have its own development environment. If you were programming in C++, I would use Visual Studio, which you can download and use for free (for small business/non commercial projects). We do not have any guides for using VS or for setting up your development environment.

Regards,
Andrew

[stevecrm]

For reference these are my capture settings

`bb_api.bbConfigureCenterSpan(id, 70000000, 4.0e6); //center hz, span hz
bb_api.bbConfigureLevel(id, -20.0, bb_api.BB_AUTO_ATTEN);
bb_api.bbConfigureGain(id, bb_api.BB_AUTO_GAIN);
bb_api.bbConfigureIQ(id, bb_api.BB_MIN_DECIMATION, 4.0e6); //bandwidth hz

• This reply was modified 7 years ago by stevecrm.