Search Results for 'api'

[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, 2 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, 4 months ago by Andrew.
• This reply was modified 6 years, 4 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, 4 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, 4 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

It seems like that is not too difficult to get receiver power for the measurement receiver of SA44B with Visual Studio. But I can’t figure it out how to use API function for Signalhound devices. Maybe someone can help me with an example of Visual Studio code which can work with some Signalhound’s API functions?

[Andrew]

We do not have plans to develop a Linux API for the VSG25A at this point.

Regards

[firatcnur]

Do you have a shared object I could utilize in Linux to call APIs?

There are shared objects for the other signal hound product ranges, however, I did not come across one for vsg25 ( might be looking at the wrong places ….).

Regards

[Andrew]

Kaiser,

For normal sweep speed, (via the smSetSweepSpeed function) the resolution on which we can change the GPIO output is multiples of 39.0625 MHz. (N * 39.0625 MHz) If you are using the fast sweep speed, that number is 156.25 MHz but can be offset by a multiple of 39.0625 MHz. (N * 156.25M + 39.0625M * [0,1,2,3 depending on factors]) If you use the same sweep settings, the API will be consistent about what LO steps it changes the GPIO on.

I believe the logic is, that if your GPIO freq exceeds the freq calculated from the equations above, then we perform the switch. If you use these multiples directly, pick a number slightly higher to force the switch.

It sounds like you just need to nail this down for just a couple sweep configurations? This should be enough information for you to start adjusting the frequency on the GPIO steps and choosing the best values for your sweeps?

Regards,
Andrew

[Andrew]

Hi Kaiser,

I updated the SDK with a rebuilt SM API 1.1.7. I tested it on Ubuntu 18.04 before uploading. I’m not sure where it got corrupted before. Thanks for your patience.

Regards,
Andrew

[ray62202]

Kaiser, I was able to find out that the library image was corrupted with the following command:

$ readelf –a libbb_api.so.4.0.2

The output of readelf will tell you about the different pieces of the library, and if they are corrupted. Substitute the file name of the library you are using in the command.

Andrew updated the library for me, and I’ve been cruising along just fine ever since.

– Ray

[Andrew]

Kaiser,

I will look into this.
Which build of the SM API are you using and on which OS?

Thanks,
Andrew

[kaiser]

Is it possible that we’re seeing something like that also in the sm_api.so file in the downloads? Getting a very similar linker error

“/usr/bin/ld: out of memory allocating 1189565853043737155 bytes after a total of 186720 bytes”

when trying to compile a very basic program (just trying to open the device), and I just earlier today used wget to get the file, unzip it and grab the .so file.

Thoughts?

[Andrew]

Kaiser,

I don’t think the GPIO sweep switching is going to be adequate for your task since you are doing the 100MHz spans. It was originally designed to antenna switch over multiple GHz sweeps. It only operates at the granularity of the LO step freq which is 160MHz in your case, or 40MHz in the slower sweeps.

The I/Q GPIO switching you saw does not work in sweep mode.

Thinking about what we could add to the API, what if the API gave you the ability to queue GPIO switches in between sweeps. For instance, insert a single GPIO switch in between StartSweeps? Do you think this would be adequate for your measurements?

I don’t think it would slow down the sweep speed at all.

Given the 100MHz span, I think you would have to give up sweep speed to accomplish what you need with our current API.

If you think the proposed solution would work, I can potentially look into adding this for a future update? You could simulate this by calling
smGetSweep() -> smSetGPIOState() -> etc..
albeit at a slower sweep speed.

Regards,
Andrew

[kaiser]

Also, real quickly. Why is the C# API declaration for smSetGPIOSweep commented out for the structs? It should be fairly simple to pass an array of structs from C# to C++, like so:

[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);

Is there some mismatch or oddities on the other side? It’s just two fairly straightforward variables.

Edit: If I put one of the GPIO’s on the O-scope, and run the GPIO Sweep sample code with this change in C#, I get a waveform that looks about right….

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

[kaiser]

Thanks for the detailed reply Andrew. Like I said, interrupts would be the best case. I’ve extensively used to National Instruments samplers, and my understanding form talking to their engineers is that they open multiple pipes on the USB connection; one for high bandwidth streaming, and one for low latency notification. So, for example if I’m sampling 32 inputs at 16-bits, 30kHz I get a stream very similar to what I get from the SM200A, but also can have extremely low latency notifications (non-deterministic of course, but low latency) of events like sample start / sample end or change detection on some pins. I imagine that it would complicate your drivers somewhat and might not be worth it. Like I said, in a perfect world 🙂

What I’ve done is grabbed one of our microcontrollers (a SAME54 board) from the back, and am working to integrate that. The thought is that I can use the GPIO of the SM200A to notify the microcontroller of when a sweep end. The microcontroller gets an interrupt, and then communicates with the attached equipment to prepare it for the next sweep while the SM200A is running.

Basically, I need to keep the SM200A sweeping my 100MHz band of interest at the 0.3ms sweep time that I am getting now, but also in between sweeps configure my support hardware for the next sweep. I can’t afford to let the sweep time increase any, and I have to sweep the entire 100MHz, can’t get it down to 40MHz.

The microcontroller in debug mode yesterday could update the support hardware at >100kHz, so I should be able to keep the SM200A in fast sweeping mode, and just upon notification of the sweep end (or that the sweep has hit a certain frequency to account for any latency), update the equipment while the SM200A prepares for the next sweep.

I’m running through a couple hundred test states of the support equipment while this happens. So, the best way would be for the GPIO to essentially increment/change every scan. But I don’t see exactly how I could do that with the GPIO; it seems to be more inter-scan focused than intra-scan focused or time-based (which might work).

So let’s talk GPIO:

If I use GPIO sweeping, does it reset every sweep, or run independently? Say I.m sweeping up to 2.9-3GHz. If I set the GPIO sweeping to increment every time I pass 2.99GHz, would it continue to increment every sweep, or reset? If it just continually incremented down the list, that would be awesome. If it resets, then I can probably make it work, but then move a ton of functionality to the microcontroller and end up with potential for them to get out of sync (microcontroller counting pulses, and running the show rather than the main computer telling it which state to go into). Guess that I can probably test this.

With GPIO switching — the examples I saw show it going alongside IQ streaming, and the API indicates that it’s “output while the device is streaming IQ data”. So I assume that it doesn’t work with regular sweeping? If it did, is the timing good enough between it and the sweep, that I could get/keep them synchronized? I didn’t see a great mechanism for that, and am unsure how I would synchronize, but could be missing something.

Still just trying to find the right way to skin the cat here 🙂