Search Results for 'api'

[jams90]

I get my TG44A to work on C# with the TG_API.dll

thanks!

[jams90]

Hi, i’ve read about the StandAlone API and downloaded it with the PDF file wich explains the functions but i can’t get the API to work on C#.

is it posible to use it on a C# forms project?

[Justin Crooks]

Lou,
The way spur reject works is by mixing the incoming RF using two unique combinations of local oscillator and sometimes a different IF frequency. The results are compared and a signal not present in both is rejected as probable spurious.

In essence, a signal that is present for the entire sweep (or, for large spans, the time it takes to sweep 21.4 MHz) will not be rejected or hidden. We show our internal clock noise, rather than hiding it and risking missing an actual signal.

If a signal is pulsed or rapidly frequency hopping, spur reject may reject the actual signal, which is why for these types of signals, spur reject mode must be disabled. To analyze these types of signals, the BB60C is strongly recommended, although if you know the frequency of the signal, the SA44B in real-time mode may work also.

[Andrew]

Hi Labbench1,

Yes I did. I have made a note to notify you when the API has been compiled on Linux and is on the website. I suspect early next week. I’ll make a point to do it on Monday or Tuesday.

Apologize for the wait.

Regards,
A.J.

[Andrew]

Hi Andrew,

The trigger values in the current API provide you with the full resolution pre-decimation. The BB60 has a sample rate of 80MS/s which we convert to a 40MS/s I/Q data stream with decimation 1. The triggers are referenced to the 80MS/s. So at a decimation of 1, you would need to divide a trigger value by 2 to have it reference a sample in a 40MS/s I/Q stream.

If you have a decimation of ‘n’, divide the trigger value by (n*2) to have it reference a sample in your data stream.

Alternatively, the trigger values range between 0 and 2^20 (1048576), so if your getting 8192 samples per acquisition, divide the trigger value by the ration of 2^20 / 8192 = 128.

The reason it is this way, is so that the triggers are still providing 12.5ns resolution for any I/Q data stream.

Regards,
A.J.

Hello.
I work with BB60 API IQ example with trigger functionality.
My buffer length is 8192 samples (625kHz samplerate with 300kHz bandwidth) but trigger array gives me values like 100000 and bigger.Is it wrong or this values are not indexes in data array.

I am following the instruction from this page https://signalhound.com/download/spike-api-for-armv7-a-linux/. But i still cannot run the example “full_span_peak_search”. This is my Signal Hound serial numbers : 30300391
OS : Rasbian Wheezy

How do i know my Signal Hound Firmware Version ? Should i upgrade it ? And How do i upgrade it ?

Thanks, and sorry for my bad english

Attachments:

You must be logged in to view attached files.

[Andrew]

Hello rmaso,

Someone else might be able to assist you further. I don’t have experience with Labview but I found this response earlier in this thread.

If you have installed the Signal Hound Spike application, look in this folder.
C:\Program Files\Signal Hound\Spike\api\sa_series\labview
This is a Labview example we distribute. Another forum member was able to verify this worked out of the box. If this example works for you, then maybe you can determine what is causing issues with your setup.

Regards,
A.J.

[Andrew]

Of course,

Since you are using the Atom CPUs, it would be good to characterize the behavior on Windows first. Our application uses the API under the hood, so you can get a good idea on how various features work. The API functions similarly on both Windows/Linux, so when I get it recompiled, porting should be easy, if you are able to start development on Windows. Shoot me an email at aj at signalhound dot com and I will email you when I get a new Linux version up. I can’t guarantee any time frame though, maybe in the next couple weeks.

Regards,
A.J.

[Anonymous]

I use 32bit spike API in Windwos 7.
Next bring the thread function code
After each call bbFetchRaw stack pointer decreases on 12 byte

while(!Active)
{
if(reconfigure)
{
bbAbort(DeviceID);
bbConfigureCenterSpan(DeviceID, Freq, Bandwidth);
bbConfigureIQ(DeviceID,64,Bandwidth)
bbInitiate(DeviceID, BB_STREAMING, BB_STREAM_IQ);
reconfigure = false;
}
bbFetchRaw(handle, &data[0], 0);
PostMessage();
}

[Andrew]

Hi John,

The main reason one might buy a BB60A now is due to price. We do not sell the BB60A anymore and have not since the BB60C was released.

The BB60C hardware design is drastically different than the BB60A, as you noted. The BB60C uses a direct RF path for frequencies below 20MHz. The HDSDR application requires an input I/Q data stream to operate on. We have not developed the direct RF to I/Q code necessary for HDSDR. This only affects 20MHz and below. Our API is available to users and we do provide the code for our device to interface HDSDR, so if you have programming experience, it would be possible to fill in the missing pieces to get the direct RF into HDSDR. This would require C++ and signal processing experience.

Regards,
A.J.

Hello
In bb_api.h BB_MIN_IQ_BW is disable. So …
How can I know IQ bandwidth lower limit for any sample rate ?

[Justin Crooks]

Have you tried closing the device and re-opening it? If you are using the Spike API, this will likely work. With the older API, I believe there is a SHAPI_CyclePort or similar that should accomplish the same thing.

Does anyone have a suggestion on how to restart a stuck DLL when using Labview? Problem I am having is when I lose connection to a SA124B, for example during a trace request. I cannot regain control of the analyzer through the DLL.
Second question. Is the serial protocol for the SA124 published anywhere then I could go direct to the USB port and reset the connection to the analyzer with out having to use the DLL.
Any suggestions would be appreciated.
Thanks.

[Andrew]

Hi Cyprien,

If you have installed the Spike x64 application on your PC, you can get the 64-bit version of the ftd2xx.dll library from the Spike installation directory at C:/Program Files/Signal Hound/Spike/
You will see the ftd2xx.dll file that Spike uses, which you can copy into the same directory as the bb_api.dll file for your application. This should resolve the error you are seeing.

Regards,
A.J.

Hi,

I am operating on a vanilla windows 10 PC with has a functioning Spike x64 (3.0.16). However, I am having issues with bb_api.dll because it bombs due to ftd2xx.dll not being found (both x86 and x64). I have uninstalled and re-installed the drivers to no avail, so I have manually copied the DLL into my exe folder. The x86 version works OK, but when use the bb_api.dll x64 it is a problem. Using dependency walker I notice that the bb_api.dll x64 has a reference to ftd2xx.dll, but the “CDM v2.12.06 WHQL Certified” package contains the dll ftd2xx64.dll which is presumably is the DLL that should be in use. Have I misunderstood or is there a DLL naming issue?

Also any pointers on getting this working without having to copy the ftd2xx.dll to my install folders.

Thanks.

[Andrew]

Hi Martin,

Thank you for the heads up on this. This is a known limitation right now. I will be releasing a version today 11/9/2015 that addresses this. The function call will change from saEnableExternalReference to saSetTimebase(device, SA_REF_EXTERNAL_IN). The external timebase will be reset when calling the saCloseDevice function so it should be able to be set again once you re-open the device, without reloading the DLL.

Keep an eye out for that. Version 3.0.9 of the SA api. It will be released with version 3.0.17 of Spike.

Regards,
A.J.

Hello,

I’m programming my own software application for monitoring frequency drifts by processing the I/Q stream from the SA44B. I am using the latest API (the one from 10/26/2015).

For development purposes I use the following setup: SA input connected to the output of Agilent 33500B waveform generator, SA freq. reference input connected to 10MHz output of 33500B on the backplane.

I encountered the following problem:
When I for the first time use the sequence of the API calls like
saOpenDevice, saEnableExternal, saConfigCenter, saConfigLevel, saConfigIq, saInitiate, saQueryStreamInfo, then repeatedly call saGetIQ and then finally call saAbort and saCloseDevice, everything works fine.

BUT then when I for some reason do not unload the SA_API.DLL and use the same sequence of API calls like above the SA44B ignores the reference frequency input and acts like it is detuned by approx. 6 Hz while using 10MHz center frequency.

If I programmatically unload SA_API.DLL after saCloseDevice or saAbort everything is okay again after the next using of saOpenDevice etc. This is usually no problem in C++, where DLL unloads after closing the application but for example in LabView you have to close the VI everytime to persuade it to unload the DLL and this seems very inconvenient to me.

I also tried not calling saAbort and saCloseDevice when terminating the Labview application and everything was also okay (except from saOpenDevice returning -8 of course). I looks like calling saCloseDevice and not unloading the DLL after it messes up the things.

Thanks in advance for any reaction

Martin

Hi,

When querying the real-time API bbQueryRealTimeInfo the frameWidth does not appear to be the same as the sweepSize. What controls this dimension and is it user settable?

I was hoping to get the distribution of amplitude for each point in the FFT and then calculate peak to average and the CDF, but I guess I have misunderstood the function and purpose. The signal I am looking at is transient hence the use of real-time mode.

Any help on how to do or if I am barking up the wrong tree?

I am using a BB60C

Thanks.

[Andrew]

Hello zhubajei,

I’m assuming you are targeting the same architecture on both PCs? If you are using Labview 32-bit on one PC and 64-bit on the other, that might be an issue. The error message you have received, “SH_API.dll not found” is a big red flag. This message has to be resolved first. It is possible the Labview configuration has changed on the tablet PC and Labview is looking for the DLL in a different location. (i.e. Different path variable, typos in your path?) My guess is that if you resolve this error, it will work as expected. If both PCs are running a full Windows 10 OS, there should not be any reason one would work and the other wouldn’t.

Regards,
A.J.