Search Results for 'api'

[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, 2 months 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.

[Andrew]

Hello Jolugome,

The BB60C is not compatible with the RPi. It is only compatible with x86 systems (Linux (API only) or Windows). We had support for running the SA44 on the RPi2 in the past, but no longer support this API due to USB throughput limitations.

Regards,
Andrew

[tuantuanlee]

Is there any special processing for 4096 32-bit floating point data before play it by the Windows waveout API？

[tuantuanlee]

Thanks!

I have called the Windows waveout API.
My program can play the audio file recorded by Spike now.
But,it can’t play the audio data retrieved by bbFetchAudio.

[Andrew]

Hello tuantuanlee,

You will need to use some sort of system audio API to play sound. We use the Windows waveout API in Spike to play audio, but there are many options.

Regards,
Andrew

[tuantuanlee]

I have retrieved 4096 32-bit floating point data by calling bbFetchAudio(FM mode), but i don’t know how to play the audio data in my program.

• This topic was modified 6 years, 3 months ago by tuantuanlee.

[Andrew]

To ensure the least amount of data loss over USB elevating the thread priority is the best(only?) way we have found to do this. As far as I know root privilege is required for this on Linux (not the case on Windows).

With multiple devices actively making measurements, you will experience data loss if this isn’t done.

I had another customer do a bit of testing with niceness levels and it never resulted in an adequate solution. (His processing would still swamp the CPU and cause data loss events while I/Q streaming despite using niceness levels and despite pulling his processing out into separate processes.)

Below is the snippet we use to do this. You are free to play around and determine if one of your solutions will work. The result of the pthread_setschedparam() will indicate when it fails due to privilege issues. We don’t push this status back out to the user, but I have a request to in a future update. That way the user can ensure the API is setting the proper priority. The API doesn’t check (or care) if it fails at the moment.

void ElevateThreadPriority(std::thread &t)
{
pthread_t this_thread = (pthread_t)t.native_handle();

struct sched_param params;
int tp = 10;
params.sched_priority = tp;

int res = pthread_setschedparam(this_thread, SCHED_FIFO, &params);
}

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

[kaiser]

Thanks Andrew. I’m running through what you mentioned in the Appendix of the latest API and it’s all making sense.

However, my customer’s policy is that we can’t run processes on our delivered hardware as root. Too much of a security concern there; they want scoped permissions. So I gotta get a way around that (or just use Windows, which is fine, they just prefer Linux). I can see a couple of potential ways to script this without having to run as root. Can you let me know what you think and/or test a couple of these options?

1. Add the nice command to thesudoers file with NOPASSWD. I’ve already done this for system shutdown / restart so that my application (user) can run the command to shutdown the system while not being root. Would adding the “nice” command to not require a password, and then running my application with something like a nice level of -20 (normally requires root, max priority level) result in effectively the same performance as running while root?

2. Adjust the limits.conf file and allow the user to launch applications with a higher than typical priority. Would be very similar to #1 I think, but would I think allow the pthread to get it directly without having to alter how you run the program.

3. Launch a setcap() with root during startup to allow the process itself to run at higher priority (might run into issues where just the main process / thread has high priority, but spawned processes or threads don’t? Haven’t ever used this capability so I’m not sure of any pitfalls).

Thoughts?

• This reply was modified 6 years, 5 months ago by kaiser.

[Andrew]

Kaiser,

We have several customers running multiple SM200s on a single PC. I’m aware of one customer running 4 SM’s streaming I/Q.

You are correct in that the biggest issue is generally USB throughput, but we have found that 2 SM’s will run just fine on a single PC (higher end desktop). You only really need to consider USB adapter cards above 2 SM’s.

If you are on Windows, everything should just work out of the box. If you are on Linux, take a look at the appendix in the latest API manual. I have some notes for multi-unit use on Linux.

How much processing power you need it really going to be dependent on what type of processing you add to the system. A standard 4 core PC will run 2 SM’s if you did not perform any processing.

Regards

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

[Andrew]

Hello,

We don’t have a function in the API that directly provides you the measurements that the “Measuring Receiver” does from Spike. I can tell you the general idea behind the it though.

You could reproduce it with the API by using basic sweep functionality with the flat-top window (default) and finding the peak value in the sweep. Reference level would then be used to adjust the sensitivity of the receiver as you adjust your input level to the receiver. You would want to measure the offset before and after a ref level change and include that offset in your final calculation.

A lower RBW on the sweep would get you finer frequency resolution if needed.

Let us know if you have additional questions.
Regards