Search Results for 'api'

[Andrew]

Hi HalHoffman,

The sa_api and ftd2xx DLLs do not depend on anything in the .Net framework but do depend on the VS2012 redistributables. Have you installed those yet? Have you tried using a tool like dependency walker to determine which libraries you might be missing? I believe you can use it on the sa_api DLL. Also if it is a missing library, simply compiling it with the #pragma comment(lib,””) flag will tell you which DLL is missing when you go to run it.

I am running 1909 and have run 1903 in the past, both OS run the sa_api just fine. Does Spike work on these newer computer? If yes, it is probably because the VS2012 redistributables are shipped in the Spike directory.

Regards,
Andrew

I have a C program that fails to load sa_api.dll.

The main points –

This entry is similar to another one I submitted, “Python 2.7 ctypes sa_api.dll Windows 10 1803 1903”, but is using C instead of Python and attached is a Process Monitor logfile showing thread activity.

You can see from the Process Monitor logfile is that sa_api.dll is loaded and then ftd2xx.dll is loaded. Loadlibrary returns NULL and a call to GetLastError returns 126 which means the module was not found.

This program succeeds on an older computer with Windows 10 1803 and fails on a newer computer with Windows 10 1903 or 1909. I don’t know if that is the cause of the failure but it is a difference.

The details –

The source code –
#include <stdio.h>
#include <windows.h>

int main()
{
HINSTANCE ll_handle;
int status;
DWORD err;

ll_handle = LoadLibrary(“sa_api.dll”);
if (ll_handle != NULL)
{
printf(“LoadLIbrary returned not NULL. We have a handle.\n”);
}
else
{
err = GetLastError();
printf(“LoadLibrary returned NULL\n”);
printf(“GetLastError %d”, err);
}

return 0;
}

Compiled with MinGW, gcc 8.2.0

Files in the directory –
sh1.exe
sa_api.dll from Spike 3.4.2
ftd2xx.dll from Spike 3.4.2

Running the program on the newer computer with Windows 10 1909 –
>sh1
LoadLibrary returned NULL
GetLastError 126
>

Error code 126 is ERROR_MOD_NOT_FOUND, “The specified module could not be found.”

From Process Monitor (sysinternals.com) logfile –

11:53:53.2685325 … Load Image …\sa_api.dll SUCCESS …
11:53:53.2792824 … Load Image …\ftd2xx.dll SUCCESS …

Attached is the logfile that shows all the thread activity. It does load both dll’s and every event has a result of SUCCESS.

Do the dlls sa_api.dll and ftd2xx.dll depend on the Microsoft .NET Framework? The older computer has version 4.7.03056 and the new computer has 4.8.03752.

Do you know if these dll’s have run on a computer with Windows 1903 or 1909? Can you try that?

Can you think of any other examination I can do?

Thanks for whatever help you can provide. At this point I can’t use an SA124B or SA44B with a new computer.

–

Attachments:

You must be logged in to view attached files.

[HalHoffman]

Yes, the ftd2xx.dll file is in the same directory. I had moved the dll files from “Program Files (x86)/Signal Hound/Spike” to this test directory to make an example with the fewest files possible.

I had done another test where the example program opened ftd2xx.dll instead of sa_api.dll, and that was successful.
sa_dll = ctypes.CDLL(“ftd2xx.dll”), so ctypes found that file. I don’t know if that is a useful clue.

Another observation is that with this same computer, running Window 1903, my software failed to open a DataQ data logging module, while it was successful with several other computers running Windows 1803. It generated a different error. It is curious that access to two different devices would fail with the new computer.

Thanks

Has anyone seen this behavior?

I have a Python program using ctypes to load sa_api.dll. It works on an older computer with Windows 10 1803 and fails on a newer computer with Windows 10 1903. Both with Python 2.7.7 and 2.7.17.

Files in the directory –
ex1.py
sa_api.dll

The source code –
# ex1.py
import ctypes
from ctypes import wintypes
sa_dll = ctypes.CDLL(“sa_api.dll”)
print “Open sa_api.dll success”

Running the program on the newer computer with Windows 10 1903 –
>python ex1.py
Traceback (most recent call last):
File “ex1.py”, line 4, in <module>
sa_dll = ctypes.CDLL(“sa_api.dll”)
File “C:\Python27\lib\ctypes\__init__.py”, line 365, in __init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] The specified module could not be found

On a different computer running Windows 1803 this code runs correctly.

It is curious that ctypes cannot find the file sa_api.dll which is in the same directory as the program.

I believe the two computer are setup the same way regarding this. Their python paths (sys.path) are the same.

I suspect that this version of Windows has broken something.

Has anyone seen this behavior and have ideas of a workaround?

Thanks

[Gary]

Thank you for the response. I’m confused, however. According to the Signalhound API manual, you use the 3 dB points to create the variable-width RBWs. But the value “2.02” for the Nuttall also matches the value for the table at the end of the API manual. That is the ENBW. The 3 dB value, according to my calculations, is around 1.9 bins for your Nuttall.
Any idea what I’m misunderstanding?

[Andrew]

Hello thientran,

The API you are currently using has been deprecated and we unfortunately don’t support it anymore. Several years ago we released a newer API for the SA44B which you can download in our SDK at the link below.

Using the newer API, I would configure a sweep and use the sweep data to measure the amplitude at a given frequency. You can use the Spike software to determine the sweep settings needed for your measurement and use them when setting up your sweep in the API. There is a sweep example you can use to get you started.

There is no measurement receiver function in the new API, but based on your short description, it does not sound like you need that. It sounds like a simple sweep would work.

https://signalhound.com/software/signal-hound-software-development-kit-sdk/

Let me know if you have follow up questions.

Regards,
Andrew

[thientran]

Hello!
I have 1 SA44B and I want to use it to measure the amplitude of the signal at the center frequency.
I used the function (in the API):
SA44B_Device.SHAPI_RunMeasurementReceiver(ref myMeasRcvr);
AmpliFreqCenter = myMeasRcvr.RFAmplitude .
The data receiving speed is very slow (about 500 ms / 1 sample). How to improve the speed?
Thank!

• This topic was modified 5 years, 10 months ago by thientran.

We have developed a C# application that uses the SA device API.

We see that the same application, connected to the same device, has very different performance on 2 PC with the same hardware (Intel Core I7).
On the first PC the saGetSweep_64f call takes 200ms to return the data.
On the second PC the saGetSweep_64f call takes 400ms to return the data.

Is there any reason for this behavior?

Thanks,
Filippo

[Andrew]

We don’t provide any BER testing capabilities. One could use our APIs to manually perform BER testing. EVM measurements are sometimes used as an alternative/approximation to BER testing. We don’t have resources for doing this.

Regards,
Andrew

[kaiser]

Upon further investigation, you can change the sm_api.cs to just be like:

[DllImport("sm_api", CallingConvention = CallingConvention.Cdecl)]
    public static extern SmStatus smGetDeviceList(int[] serials, ref int deviceCount);
    [DllImport("sm_api", CallingConvention = CallingConvention.Cdecl)]

Then if you’re on Linux, it looks for sm_api.so, libsm_api.so and on windows it looks for sm_api.dll

Nice little benefit for interoperability. If you need to specify x64, x64 and other arch’s, you’ll probably need to SetDllDirectory or LoadLibrary with a dynamically added name, or a custom build step to rename the proper dll and put it with the assembly. DllImport only can do so much matching.

[kaiser]

[StructLayout(LayoutKind.Sequential)]
public struct SmGPIOStep
{

public double freq;
public Byte mask; // gpio bits

public SmGPIOStep(double f, Byte m)
{
this.freq = f;
this.mask = m;
}
}

[DllImport(“sm_api.dll”, CallingConvention = CallingConvention.Cdecl)]
public static extern SmStatus smSetGPIOSweep(int device,[In, Out]SmGPIOStep[] steps, int stepCount);

I just downloaded the latest API, and was running it against some of my code. I had to edit the sm_api.cs again to add this in, so that I could set up GPIO Sweeps from C#. It seems to work great again. This is the 3rd project where I’ve had to make this edit, as suggested here. Is there any reason why this bugfix hasn’t been included in the sm_api.cs file yet?

Really more of an FYI if anything.

I had a Windows C# application that we used for initial development of some algorithms and functionality for a customer. It worked quite well.

Then another customer required CentOS Linux. We re-wrote the application in C++, which was fine. It worked. We were sad to see many of the niceties of C# fade away, but there’s nothing wrong with C++, if you’re used to it.

We now had a need to harmonize code-bases, as we started implementing features moving forward.

Was playing with .Net Core 3.0 preview for Linux / Windows, and decided to try and get our C# code running on Linux. So we set up a CentOS 7 box, got everything installed nominally. Created a .Net Core 3.0 application, and then in the sm_api.cs (in the windows examples directory), merely replaced all “sm_api.dll” with “sm_api.so”, and it just worked.

So to anyone out there wondering if this is possible, or how well it works, or how to do it, or what they should do for cross-platform development, I’d heavily recommend .Net Core. VS Code can SSH into multiple remote computers either Linux or Windows, remote develop/build/debug and it works great. You can also deploy the same application via docker, and so on. In fact, the debugger works much better with respect to pausing the SM200’s queued captures and then re-starting than gdb ever did.

Enjoy all, and good job Signal Hound team!

[LVXICHEN]

Andrew，Thank you for your reply。Due to the limitation of using environment, we can only use ARM hardware platform，Does SA44B support this use? Why don’t you support API on ARM now? Is it due to fewer users or to technical reasons? What will happen if we connect SA44B on ARM Corex-A8?
We look forward to your reply！

[Andrew]

Hello,

As you’ve noticed, the SA44B ARM packages in the SDK are located in the “obsolete” folder. This is because we have obsoleted/deprecated these versions of our APIs and no longer support them. We recommend Windows only due to the limitations which you can read about in this thread.

Regards,
Andrew

[LVXICHEN]

Hello，I want to connect with SA44b on the ARM Cortex-A8 hardware platform, and get the transmitting power and frequency of wireless devices through API interface function，Can I use it this way? Are the packages of”arm_sa44B_api.zip” provided on your website fully tested and ready to use?
The File of “arm_sa44B_api.zip”is Under “Signal_hound_sdk_07_15_19-SDK” Software Development Suite Compression Package

[Andrew]

Our APIs are not open source. Additionally, the FTDI library is only used in the BB60 API for the tracking generation compatibility. The BB60C itself uses libusb for USB 3.0 communication. The BB60C has a complex and proprietary protocol that we do not publish.

Regards,
Andrew

[asvol]

Thank for your answer. May be you can give us source code bb_api library. We can try to compile your library for ARM. Or maybe you can explain how to get raw IQ data from device throug ftdi without using your library. We use your device for fly on drones and we didn’t want use x86 compatible PC, because it’s too greedy for power.

Hello.
We have device BB60C Spectrum analzer and we want use it with Raspberry PI 4 with ARM CPU arhitecture. Can you build libbb_api.so and libftd2xx.so files for this platform.

[Gary]

UPDATE: SUCCESS! Turned out I needed to load “swig” (available in Software Manager). Once I did that, then went through the process from “cmake ..” on down, I opened GRC, ran the flowgraph, and it worked!

Once I summarize my notes (they’re, uh, kinda messy), I’ll post another thread explaining how I did it.

Thanks, again!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Long story short: I had tried to install Gnu Radio from source and with Pybombs, both of which gave me more errors than did the BB60C “cmake..” command. I followed your links and the answer was to install “gnuradio-dev”.
However, even with that, I kept getting:

/sbin/ldconfig.real: /usr/local/lib/libftd2xx.so is not a symbolic link

/sbin/ldconfig.real: /usr/local/lib/libbb_api.so.4 is not a symbolic link

after the “sudo ldconfig” command.

I thought it might still work, so I opened Gnu Radio Companion and added the “BB60C: IQ Source”. However, when I attempted to run the simple flowgraph (it was simply attached to a frequency sink to look at the spectrum), I got the following errors in GRC:

Generating: '/home/gary/gnuradio/bb60SpectrumAnalyzer.py'
>>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.

Executing: /usr/bin/python -u /home/gary/gnuradio/bb60SpectrumAnalyzer.py

Warning: failed to XInitThreads()
qt5ct: using qt5ct plugin
Traceback (most recent call last):
  File "/home/gary/gnuradio/bb60SpectrumAnalyzer.py", line 156, in <module>
    main()
  File "/home/gary/gnuradio/bb60SpectrumAnalyzer.py", line 144, in main
    tb = top_block_cls()
  File "/home/gary/gnuradio/bb60SpectrumAnalyzer.py", line 116, in __init__
    self.bb60c_source_0 = bb60c.source(1e9, -20, -1, -1, 2, samp_rate, False, False, 0, 0)
AttributeError: 'module' object has no attribute 'source'
inotify_add_watch("/home/gary/.config/qt5ct") failed: "No such file or directory"

I don’t know if those two issues are related.

Thank you for the help. I think I’m pretty close to making this work. Once I do, I’ll do a short write-up explaining to others how I got it to work in Mint 19.1.

• This reply was modified 6 years, 1 month ago by Gary.

Hello,

I’m working with a SA44B using the API in Python. I’m able to utilize the API just as I would have anticipated.
The issue I’m having is that the “min” and “max” arrays values don’t correspond to dBm as I would have suspected. The values do follow the level as expected, but not the values. An example is attached.

Is there a function to convert these values to dBm?
Perhaps it has to do with the way that I instantiate the two arrays? This is the code I’m using to create the min/max arrays before calling the saGetSweep method, where swlen is the length of the sweep

        pyarr = [x for x in range(swlen.value)]
        arr = (ct.c_int * len(pyarr))(*pyarr)
        arr2 = (ct.c_int * len(pyarr))(*pyarr)
        min_pointer = ct.pointer(arr)
        max_pointer = ct.pointer(arr2)
        res = self.sa.saGetSweep_32f(self.deviceHandle, min_pointer, max_pointer)

Attachments:

You must be logged in to view attached files.