Search Results for 'api'

Hello,

I am using the linux API and have been reading the manual and testing a few things with the SlowSweep function. The manual states that the product of avgCount and FFTSize must be evenly divisible by 512.

Here is the code I am running:

#include <cstdio>
#include "CUSBSA.h"
using namespace std;

int main()
{
    CUSBSA mySignalHound;
    mySignalHound.Initialize();
	mySignalHound.Configure(0.0,1,2,1,0,0);
	mySignalHound.SetPreamp(1);  //turn preamp on

    int i,returnCount = mySignalHound.SlowSweep(162.390e6, 162.56e6,8192,16,0);
	printf("#RBW: %f Hz\n", mySignalHound.m_dCalcRBW);
	
    for(i=0; i<returnCount; i++)
		printf("%3.8e   %3.3f\n", mySignalHound.dTraceFreq[i], mySignalHound.dTraceAmpl[i]);

    return 0;
}

I can run SlowSweep with FFTSize=4096 and avgCount=30 and successfully get the result. But if I try to increase avgCount to 32, it looks (judging by the front panel LED) like the SA44 does the measurement, but hangs at the point where it is sending data back to the host.

If I lower FFTSize to 2048 and avgCount to 32, it works. If I run 8192 and 14, it works, but 8192 and 16 fails. Based on these and other tests, it seems that
(FFTSize x avgCount) / 512 must be less than 256
for the SA44 to successfully perform the measurement and return the data.

Is this correct? and expected?

Thanks,
DAN

[dbreton]

Hi A.J. et al,

I am also trying to get the Signal Hound to work with embedded linux, specifically the TS-7670. I’ll simply be logging the output to files, no GUIs involved.

I am having a similar problem with the libSHLAPI.a file, though my machine/compiler complains:

g++ CUSBSA.cpp -o USBSA.o
g++ main.cpp CUSBSA.o libSHLAPI.a /usr/local/lib/libftd2xx.a -o test_shapi -lpthread -ldl -lrt

libSHLAPI.a: could not read symbols: File format not recognized
collect2: ld returned 1 exit status

Is there any way I could get the source files that go into the .a library? I’d like to try to compile them on my machine to see if there is some weird architecture thing that is keeping this from working. Failing that (e.g. those libraries are proprietary or something) can I send you information about my processor and toolchain for cross-compiling?

Thanks in advance,
DAN

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

[Andrew]

Hello Feng,

You did not state whether you are using the API or using our supplied software. If you are using our software then you can setup video triggers in zero-span mode using the control panel. If you are using the API and retrieving IQ data from the device directly then video triggering is just a function of checking each IQ sample for you trigger level.

If this does not answer your question, please try to restate your questions.

Regards,
A.J.

[Andrew]

Hello Filippo,

We do have an example. If you go into the bb_series folder we have a fully fleshed out API in the csharp folder for our BB60 API. The BB60 API is very similar to the SA44/124 API so it will be mostly cut and paste.

The mechanism by which this is performed is commonly referred to by many names, most notably as PInvoke, Interop, or marshalling. These are the mechanism by which a C# program can call a C function in a DLL on Windows. Searching the internet for these terms will return many examples of doing this.

Regards,
A.J.

Hi,
how can I use APIs for the SA devices (sa_api.dll) on a .NET application?
Is there any ready sample?

Regards,
Filippo Marchese

[Andrew]

Hello Feng,

Video and External(BB60 only) triggering is available in Zero-Span mode. You can configure the triggers on the control panel after entering Zero-Span mode. In the API no triggering is performed directly, but the location of external triggers are returned when the API is configured correctly. You can see the API manual to learn more about setting up external triggers. https://signalhound.com/sigdownloads/BB60C/BB60-API-Manual.pdf

Regards,
A.J.

[tr_feng]

Hi Andrew,
Thanks for your quick response, another question is how to setup a trigger through software/API ? and how many types of trigger do BB60C support? voltage level? power trigger? mask trigger?
Thanks!

[Andrew]

Hello Marholt,

The Windows libraries have received a major update over the last couple of weeks. You can get the libraries by downloading the Spike software package here. signalhound.flywheelsites.com/spike You can find the library file and API manual in the api folder in the application directory after installation. The API does not provide channel power measurements directly but returns sweeps on which you can perform your channel power measurements.

Regards,
A.J.

Using the following code, I set the RBW & VBW to 10 and acquire data:

saOpenDevice(handle)
saConfigCenterSpan(handle, 3000.0, 200.0)
saConfigAcquisition(handle, SA_AVERAGE, SA_LOG_SCALE)
saConfigLevel(handle, -10.0)
saConfigSweepCoupling(handle, 10, 10, True)
saInitiate(handle, SA_SWEEPING, 0)
saQuerySweepInfo(handle, sweepLen, startFreq, binSize)
saGetSweep_32f(handle, min, max)
saCloseDevice(handle)

What is returned: binSize = 1.854
I was expecting 10, or at least close to 10. Is this normal?

[Andrew]

Thank you for the heads up on the Linux API. I can look into it. Are you looking to stay on Linux or use Windows to take advantage of the new API updates?

Our Linux APIs (non-ARMs) required low-latency kernels and do not include any updates made over the last couple of years.

Regards,
A.J.

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

[marholt]

Thank you for the info.
We are searching for new board that will have x86 or x64 processor.

I’m trying now to compile the 32-bit linux version api (https://signalhound.com/sigdownloads/SA44B/linux_shapi_x86.zip)
but compiler is showing an error that the library libSHLAPI.a is incompatible with x86.
“i386:x86-64 architecture of input file `libSHLAPI.a(myFFT.o)’ is incompatible with i386 output”

[Andrew]

Hi Jbluff,

A couple quick questions. What happens when you launch the software (with the device plugged in and the light green) after the device has been plugged in for many minutes? Does the software find the device first try then? Also, does the API ever find the device? Even after many minutes of being plugged in?

The Option 2 is unique in that it needs to be plugged into the PC for several minutes before warming up to be operational. I want to rule that out as a possibility first.

Feel free to email me at aj@signalhound.com if you prefer email.

Regards,
A.J.

I’m having trouble reliably connecting to my SA124B (opt2).

After installing the USB drivers and Spike, I plugged in the SA and the light came on, green. When I start Spike, the light turns red, and eventually spike says the device wasn’t found. I can close spike and the light stays red. IF I leave spike open, and unplug and replug in the SA, the light is green, and in spike I can connect to the device using File->Connect, and get reasonable traces out.

Why is this?

I’m also getting “Device not found” errors when I try to open a connection using the API, though when I request the list of connected serial numbers my device appears. I assume these two problems are related. Any advice?

Thanks
Jacob

[Andrew]

Hello Marholt,

Thank you for the follow up. We have not tried other small portable solutions such as the Raspberry Pi or other alternatives. Might I suggest an x86 alternative such as a tablet or netbook with an Atom processor or Celeron processor? There might be x86 single board computers that work, I believe Intel has released a few in the last couple of years below $100. We just released a major update to our SA44 API which is compatible with x64 and x86 processors. This is the route you might have to take if you are looking to avoid longer sweep times.

If you have any further questions, let me know.

Regards,
A.J.

[Bruce]

We are scheduling the release date of the SA/TG software rewrite for 10 Feb 2015, which is less than a month away. I would like to notify you of the great strides we are making regarding the functionality of the software. This rewrite integrates the SA/TG-series devices into the BB60C open source spectrum analyzer/GUI software platform which will now work with all Signal Hound products, past and present. The new software also allows the SA’s to function as real-time spectrum analyzers for sweeps of 250 kHz and less—that means every RF event will be captured when using spans that are ≤250 kHz. Another improvement is 8x faster sweeps at a 500 kHz span, and 2x faster sweeps at a 5 MHz span with a linear transition between the two stated spans. In addition, the SA graphics now include color persistence and a 2D waterfall display. The TG devices are also benefitting from the rewrite. Long standing stability issues are resolved, to include making the high dynamic range user friendly and efficient.

Developers will be able to change the open source spectrum analyzer/GUI code, which makes its function calls to a unified and compiled API. Modifying, adding, and deleting functions, layouts, and utilities in the SA and TG devices is now possible. A liberal software license allows developers to compile the modified spectrum analyzer code for redistribution. All the great spectrum analyzer/GUI code that has been written for the BB60C, and the lessons learned, is now leveraged in the SA and TG devices. Even though the SA-series devices are hardware limited when compared to the BB60C, they can now enjoy the flexibility and power of the BB60C software platform. Best of all, the new software is going be a free download. This has been made possible because of the continued support and loyalty of the Signal Hound user community.

Best regards,
Bruce Devine
Signal Hound Owner & CEO