[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 ago by kaiser.

[kaiser]

Great Andrew, thanks for the useful and prompt response, like always 🙂

My mechanical guy is wondering if you have a model? If not he can model one up in SolidWorks.

• This reply was modified 6 years ago by kaiser.

That would be a pretty neat feature. If added, I’d like to also be able to show the same frequency if the scan rate is faster than the update rate. Like if you’re getting 5 sweeps per Spike update, being able to display all five stacked like this would be nice for picking up some detailed waveform characteristics and timing without having to write custom software.

But that likely make implementing this feature harder 🙂

[kaiser]

To pick up this thread some Andrew, I’m currently running into something that may or may not be an issue.

For example, if I set GPIOs like this:

int gpiosteps = 2;
SmGPIOStep Steps[gpiosteps];

Steps[0].freq = 2.40e9;
Steps[0].mask = 0x00;
Steps[1].freq = 2.47e9;
Steps[1].mask = 0x0F;

and look at it on the O-Scope, I get the exact same pulse as if I set something like this:

int gpiosteps = 2;
SmGPIOStep Steps[gpiosteps];

Steps[0].freq = 2.40e9;
Steps[0].mask = 0x00;
Steps[1].freq = 2.49e9;
Steps[1].mask = 0x0F;

With the frequency of the second step 20MHz further down the line.

So, my concern is when the GPIO goes low, what frequency is it actually going low at? Is it 2.4GHz, or that plus/minus 40MHz? 60MHz? 160MHz?

Like I said, I’m triggering external test equipment, and in this example Step2, when the GPIO goes high, it causes an interrupt in our microcontroller that goes and sets up the next piece of equipment. We’ve gotten the timing such that that setup is done and complete before the GPIO waveform goes low, but not by much.

But we know that it going low isn’t happening *exactly* at 2.4GHz, and so we might be making our timing…or we might not.

So, I understand that figuring out where those GPIO transitions ARE happening is tough; but I really do need to know. I can do complex things, or if it’s just a one-off where you can just tell me where it’s happening based upon my sweep parameters, that’d be great. If I need to write 500 lines of code to figure it out, great also. If I request certain frequencies, and the SM200A comes back to me with what it’s actually going to do, that would work also. But I do need to know…

This is literally our last hurdle to fielding this capability, and I’d really like to get it figured out, shipped and move onto our next fun project 🙂

Thanks!

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

Looks good and working on this end. Thanks all!

Any movement on this front? Should I try to download again, or try something else?

Thanks ray, I get essentially the same error that the link gives me “Error: Reading 1189565853043737155 bytes extends past end of file for string table” among a bunch of other errors.

So I assume that the file is corrupted, or I did something really wrong 🙂

Ubuntu 18.04.1 LTS x86_64

Fresh install.

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?

Thanks for looking into it for me.

Thanks Andrew. Anywhere to point me regarding the 160MHz frequency bin locations for calculating what bins my sweeps land in? I played with some settings of going wider, and it was hit or miss on whether I increased 0.2ms, 0.1ms, or got the GPIO working. Like I was missing a piece of the puzzle 🙂

[kaiser]

Yea, the GPIO change between sweeps would be amazing for what I’m trying to do. I simulated putting it in my queued sweeps, and it kept up for about 30 sweeps before I crash the thing 🙂 I know that’s not what exactly you were proposing, but that’s what code I had in front of me to test with 🙂 Seems like the WriteImm is pretty quick, and wouldn’t be a lot of overhead for commanded-sweeps. But I really need the speed of the queued sweeps.

With the queued sweeps, if I do increase my frequency range, then I do get a waveform I can use. Not ideal, but I can alter the architecture to make it work, and future maintenance will just be a bit of a hassle. The slowdown is *probably* manageable. It’s sweeping now in 0.4ms instead of 0.3ms. It’ll reduce the amount of data I collect to be able to say the equipment is working right, but we might still get enough. Only one way to try.

So, the 160MHz sweep bins; how do I calculate those? Like when I was scanning 100MHz, and it was taking 0.3ms you said that it was likely spanning two of the 160MHz bins. If I’m upping the spectrum I’m capturing to make this go, I’d like to intelligently add it to the left and/or right side based upon where these bins are instead of ending up spanning 4 bins and having to iteratively test a bunch to find the optimal spot…

Thanks again! Sorry for all the questions!

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

[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, 3 months ago by 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 🙂

I guess that in a perfect world, it would be neat to be able to register/get interrupts using functions similar to the GPIO setup; hey give me an interrupt when I pass X frequency, or whatever.

Excellent info Andrew. Thanks.

Thanks Andrew for the review. I had tried larger RBW’s, and smaller ones. This was the break-over point where any lower and the sweep time increased, but any higher and there was no change.

Again, thanks.

I don’t see the post I made yesterday up here, so here I go again.

As I said before, I decided to get an SM200A and see how that works. The queuing up of sweeps is huge and really this device is much faster.

Right now I’m scanning 100MHz at ~0.3ms, which is great. Theoretically it could go as fast as 0.1ms (1THz/s sweep rate). I expect that a lot of the increase in time is sweeping the LO back to the beginning of the spectrum? I’m not sure.

Either way, I’m pretty happy with the SM200A and it’s performance.
The capture is a bit noisier, which will require me to add some smoothing or similar to my algorithms, but it’s not a huge deal.
Overall, if I could eek out a bit more performance (faster scans), that would be great. Here’s some prototype code I was using to test it below; any thoughts?

Again, great device!

// Configure the receiver sweep functionality
// Things to note for THz sweep speeds
// smSweepSpeedFast must be set
// RBW must equal VBW and be above 30kHz for Nuttall window
sm_api.smSetSweepSpeed(handle, SmSweepSpeed.smSweepSpeedFast);
sm_api.smSetRefLevel(handle, -20.0); // -20dBm reference level
sm_api.smSetSweepCenterSpan(handle, 2.45e9, 1.0e8);

sm_api.smSetSweepCoupling(handle, 100.0e3, 100.0e3, 0.001); // 100kHz rbw/vbw
sm_api.smSetSweepDetector(handle, SmDetector.smDetectorAverage, SmVideoUnits.smVideoPower); // min/max power detector
sm_api.smSetSweepScale(handle,SmScale.smScaleLog); // return sweep in dBm
sm_api.smSetSweepWindow(handle,SmWindowType.smWindowNutall);
sm_api.smSetSweepSpurReject(handle,SmBool.smFalse); // No software spur reject in fast sweep
sm_api.smSetPreselector(handle, SmBool.smFalse); // No preselector in fast sweep

// Initialize the device for sweep measurement mode
SmStatus status = sm_api.smConfigure(handle,SmMode.smModeSweeping);
double actualRBW = 0, actualVBW = 0, actualStartFreq = 0, binSize = 0;
int sweepLength = 0;
sm_api.smGetSweepParameters(handle, ref actualRBW, ref actualVBW, ref actualStartFreq, ref binSize, ref sweepLength);

float[] sweepMax, sweepMin;
sweepMax = new float[sweepLength];
float[][] sweepsMax = new float[1000][];
float[][] sweepsMin = new float[1000][];
for (int i = 0; i < 1000; i++)
{
sweepsMax[i] = new float[sweepLength];
sweepsMin[i] = new float[sweepLength];
}
sweepMin = new float[sweepLength];

long[] sweeptimeEpoch = new long[1000];

//the API allows us to queue up to 16 sweeps. They recommend queueing ~4 sweeps
//but we’re pretty narrow sweeps, so let’s try 12 to start…
// Start all sweeps in queue
int sweepsToQueue = 16;
for (int i = 0; i < sweepsToQueue; i++)
{
sm_api.smStartSweep(handle, i);
}
int j = 0;
int queuePos = 0;
while (j < 1000)
{
SmStatus status = sm_api.smFinishSweep(handle, queuePos, null,sweepsMax[j], ref sweeptimeEpoch[j]);

// Process/store sweep here
// Sweep in contained in the ‘sweep’ array

// Start it back up
sm_api.smStartSweep(handle, queuePos);

// Increase and wrap our queue pos
queuePos++;
if (queuePos >= sweepsToQueue)
{
queuePos = 0;
}

j++;
}

I’ve done all of those things (shared clock, external triggers) and it got a lot better, but still wasn’t giving me the synchronization I wanted.

I did put it in IQ streaming, and and set it all up with Spike, but again it just didn’t quite get me where I wanted to go.

I bought an SM200 to give a try and see if it’s super-fast sweep time will allow me to make back-to-back spectrum measurements over 100MHz using a switch versus trying to synchronize the two BB60’s.

I’ve been thinking about using on BB60 to find the signal, and then narrow the second onto the signal and execute some quick sweeps (switching between polarizations). On Spike I can’t get a sweep faster than 6-7ms (displayed). Do you have similar sweep rates, etc so I could compute sweep acq time vs signal on/hold time and see if I might be able to get good back to back measurements?

Thanks

[Author]

Posts